Method and system for facilitating financial transactions between consumers over the internet

ABSTRACT

A method for enabling two individual consumers to complete a transaction that includes payment from one consumer (the payor, or buyer) to another consumer (the payee, or seller). An intermediary typically operates the service over a computer network of nodes, such as the Internet. The buyer has the convenience of paying through a variety of different payment instruments. Likewise, the seller has the convenience of receiving payment through a variety of different disbursement instruments. For a fee, the intermediary collects the payment from the buyer and pays the seller. Although the intermediary may receive payment from the buyer before the intermediary transfers the payment to the seller, the intermediary may choose to pay the seller before receiving payment from the buyer. In this case, the intermediary assumes the risk of nonpayment by the buyer. Alternatively, the intermediary may pay a third party that specializes in processing transactions for the payment instrument chosen by the buyer to assume the risk of nonpayment by the buyer. In this case, the intermediary receives a promise of payment from the third party before the intermediary pays the seller. Such a promise of payment from the third party is referred to as an authorization.

CROSS REFERENCE TO RELATED APPLICATIONS

This application discloses similar subject matter as disclosed in U.S.patent application Ser. No. 09/476,384 entitled “AComputer-Implementable Method for Using an On-Line Cash Register” filedon Dec. 30, 1999, U.S. patent application Ser. No. 09/476,385 entitled“Method and System for Payment Transactions and Shipment Tracking Overthe Internet” filed on. Dec. 30, 1999, and U.S. patent application Ser.No. 09/604,525 entitled “Method for Facilitating Payment of aComputerized Transaction” filed on Jun. 27, 2000.

FIELD OF THE INVENTION

The invention relates generally to computer-implemented financialtransactions, and more particularly, relates to completing a transactionbetween two individual consumers by transferring money from one consumerto the other according to transaction instructions received online fromthe consumers.

BACKGROUND OF THE INVENTION

The Internet has become a popular place to conduct business. Through Webauction sites, Web sites for displaying classified ads, Web shoppingmalls, online chat rooms, and other online transaction facilitationsites, two consumers may agree to a transaction. Frequently, suchtransactions involve the exchange of goods or services for money. Whileconsumers frequently find that agreeing to transactions on the Internetis easy, completing a payment to consummate the transaction is moredifficult.

Typically, two consumers who have agreed through the Internet toexchange goods for money resort to offline methods to perform theexchange. For example, the seller may ship the goods to the buyerthrough a shipping service, and the buyer may send a paper check to theseller.

Such offline methods of exchange are problematic. Because the buyer andthe seller are usually strangers, they may not trust each other toperform their mutual obligations under the agreement. Accordingly, theymay be unable to agree whether the buyer will send the check first orthe seller will send the goods first. Even if the buyer and the selleragree that the seller will ship the goods at the same time as the buyersends the check, the seller has no guarantee that the check will notbounce. Likewise, the buyer has no guarantee that the goods will arrivein satisfactory condition. Accordingly, a significant percentage oftransactions to which an individual buyer and seller have agreed uponover the Internet are never consummated.

Another inconvenience of transactions agreed upon by individuals overthe Internet is that the buyer is often limited to paying by cash orpaper check. More convenient payment instruments exist, such as creditcards and bank account debits through electronic fund transactions.However, the buyer typically does not have the option to use these otherpayment instruments when the seller is an individual as opposed to aretail business that has been pre-established as an online merchant.

The term “merchant” is used herein to refer to a seller of goods orservices who is authorized by a credit card association (such asDISCOVER, VISA, or MASTERCARD) to submit to the credit card associationcharges on credit cards belonging to members of the credit cardassociation. After receiving an authorization for the charge, themerchant then receives from the credit card association a direct depositinto the merchant's bank account of the amount of the charge. As knownto those skilled in the art, a business must undergo an approval processin order to become a merchant, and upon approval, the merchant isassigned a merchant number.

Although retail businesses are routinely set up as merchants in order toaccept payments through credit cards or electronic fund transactions,this is not an adequate solution to facilitating payments betweenindividuals over the Internet. For example, merchants, after undergoingan extensive underwriting effort, are typically given specialprivileges, such as a general authorization to charge credit cards. Thisgeneral authorization provides the merchant with the ability to commitfraud. Specifically, the merchant is capable of charging a customer'scredit card more than he should. Also, the merchant may submit chargeson a credit card belonging to a credit card association member withwhich the merchant has never had any contact. For these reasons, theidea of allowing individual sellers to become merchants has heretoforebeen rejected.

Another problem with an individual seller becoming a merchant is thatthe approval process for becoming a merchant is frequently more of ahassle than an occasional seller is willing to undergo. The purpose ofthe approval process is to reduce the risk of fraud by the merchant.Accordingly, the seller usually must submit extensive backgroundinformation for consideration in the approval process. This may beinconvenient and time consuming for the seller.

Therefore, there is a need in the art for a safe and convenient methodby which one consumer can pay a second consumer over the Internet.

SUMMARY OF THE INVENTION

The present invention meets the needs described above in acomputer-implemented service that enables two individual consumers tocomplete a transaction that includes payment from one consumer (thepayor, or buyer) to another consumer (the payee, or seller). Anintermediary typically operates the service over a computer network ofnodes, such as the Internet. The buyer has the convenience of payingthrough a variety of different payment instruments. Likewise, the sellerhas the convenience of receiving payment through a variety of differentdisbursement instruments.

For a fee, the intermediary collects the payment from the buyer and paysthe seller. One advantage of a consumer-to-consumer payment processoperated by an intermediary is that the risk of fraud by the seller isreduced because the buyer need not provide information about his paymentinstrument to the seller. Rather, the intermediary maintains informationabout the buyer's payment instrument in secret. Similarly, theintermediary need not provide the seller with a general authorization tocharge a payment instrument, such as a credit card.

Because the intermediary collects payment from the buyer, theconsumer-to-consumer payment process of the present invention alsoprovides the advantage of not requiring the seller to register as amerchant. Rather, the seller simply registers a disbursement instrumentfor receiving payment from the intermediary. This disbursementinstrument registration process may be simpler and more convenient thanthe process a retail business typically undergoes to register as amerchant.

Although the intermediary may receive payment from the buyer before theintermediary transfers the payment to the seller, the intermediary maychoose to pay the seller before receiving payment from the buyer. Inthis case, the intermediary assumes the risk of nonpayment by the buyer.

Alternatively, the intermediary may pay a third party that specializesin processing transactions for the payment instrument chosen by thebuyer to assume the risk of nonpayment by the buyer. In this case, theintermediary receives a promise of payment from the third party beforethe intermediary pays the seller. Such a promise of payment from thethird party is referred to as an authorization.

Generally described, the present invention comprises a method forproviding a consumer-to-consumer payment service. A payment enabler,which can be a node of a computer network, receives registration of apayment instrument from a payor located at a first remote computer. Thepayment enabler also receives registration of a disbursement instrumentfrom a payee located at a second remote computer.

Then, the payment enabler receives a command from the payor to pay thepayee an amount of money that the payor owes the payee. The command maybe the submission of the payor's registration for the paymentinstrument.

In response to the command to pay the payee, the payment enabler obtainsan authorization for a transfer of the amount of money from the payorthrough the payment instrument to a first intermediary bank account. Theamount of money may actually be deposited in the first intermediary bankaccount at a later time. After obtaining the authorization, the paymentenabler may order the transfer of the amount of money from a secondintermediary bank, which may be the same account as the firstintermediary bank account, through the disbursement instrument to thepayee. This payment to the payee may occur after authorization, butbefore the payment from the payor has been deposited in the firstintermediary bank account. Alternatively, the payment to the payee mayoccur after the payment from the payor has been deposited in the firstintermediary bank account.

The various aspects of the present invention may be more clearlyunderstood and appreciated from a review of the following detaileddescription of the disclosed embodiments and by reference to theappended drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating a typical scenario in which aconsumer-to-consumer payment process would be beneficial.

FIG. 1B is a block diagram illustrating the transfer of money in aconsumer-to-consumer payment process in accordance with an exemplaryembodiment of the present invention.

FIG. 2 is a block diagram illustrating a computer network architecturefor enabling consumer-to-consumer payments in accordance with anexemplary embodiment of the present invention.

FIG. 3 is a flow chart illustrating the steps of a consumer-to-consumerprocess in accordance with an exemplary embodiment of the presentinvention.

FIG. 4A is a flow chart illustrating a procedure for registration of aflash cash deposit as a payment instrument in accordance with anexemplary embodiment of the present invention.

FIG. 4B is a flow chart illustrating a procedure for registration ofcredit card as a payment instrument in accordance with an exemplaryembodiment of the present invention.

FIG. 4C is a flow chart illustrating a procedure for registration ofbank account as a payment instrument via electronic fund transactions inaccordance with an exemplary embodiment of the present invention.

FIG. 4D is a flow chart illustrating a procedure for registration ofvirtual private payment account as a payment instrument in accordancewith an exemplary embodiment of the present invention.

FIG. 4E is a flow chart illustrating a procedure for registration of apaper check as a payment instrument in accordance with an exemplaryembodiment of the present invention.

FIG. 5A is a flow chart illustrating a procedure for registration ofbank account as a disbursement instrument via electronic fundtransactions in accordance with an exemplary embodiment of the presentinvention.

FIG. 5B is a flow chart illustrating a procedure for registration of avirtual private payment account as a disbursement instrument inaccordance with an exemplary embodiment of the present invention.

FIG. 5C is a flow chart illustrating a procedure for registration of apaper check as a disbursement instrument in accordance with an exemplaryembodiment of the present invention.

FIG. 6 is a flow chart illustrating steps the payment enabler can followto complete the transaction between the buyer and the seller inaccordance with an exemplary embodiment of the present invention.

FIG. 7 is a flow chart illustrating steps the payment enabler can followto verify delivery of acceptable goods to the buyer in accordance withan exemplary embodiment of the present invention.

FIG. 8 is a flow chart illustrating steps for refunding money to thebuyer in accordance with an exemplary embodiment of the presentinvention.

FIG. 9 is a flow chart illustrating the steps of an auction process thatincludes static registration of the buyer and the seller with thepayment enabler in accordance with an exemplary embodiment of thepresent invention.

FIG. 10 is a flow chart illustrating the steps of an auction processthat includes dynamic registration of the buyer with the payment enablerin accordance with an exemplary embodiment of the present invention.

FIG. 11 is a flow chart illustrating the steps of an auction processthat includes dynamic registration of the seller with the paymentenabler in accordance with an exemplary embodiment of the presentinvention.

FIG. 12 is a flow chart illustrating the steps of an online cashregister creation process in accordance with an exemplary embodiment ofthe present invention.

FIG. 13 is a flow chart illustrating the steps of an online cashregister payment process in accordance with an exemplary embodiment ofthe present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention is typically embodied in a computer-implementedservice that enables two individual consumers to complete a transactionthat includes payment from one consumer (the payor, or buyer) to anotherconsumer (the payee, or seller). An intermediary typically operates theservice over a computer network of nodes, such as the Internet. Thepayor has the convenience of paying through a variety of differentpayment instruments. Likewise, the payee has the convenience ofreceiving payment through a variety of different disbursementinstruments.

Optionally, the intermediary may hold the payment from the payor inescrow until some predetermined condition is fulfilled. Once thatpredetermined condition is fulfilled, the intermediary pays the payee.If, for example, the transaction between the buyer and seller is for thesale of goods, the intermediary may hold the payment in escrow until theseller has delivered acceptable goods to the buyer. While holding themoney in trust during the escrow process, the intermediary may store themoney in a bank account.

To fully appreciate the present invention, one must understand thedifference between a merchant and a consumer. The term “merchant” isused herein to refer to a seller of goods or services who is authorizedby a credit card association (such as DISCOVER, VISA, or MASTERCARD) tosubmit to the credit card association charges on credit cards belongingto members of the credit card association. After receiving anauthorization for the charge, the merchant then receives from the creditcard association a direct deposit into the merchant's bank account ofthe amount of the charge. As known to those skilled in the art, themerchant's bank account must be pre-approved, and upon approval, themerchant is assigned a merchant number.

A consumer, on the other hand, is defined as an individual who has notbeen registered as a merchant. The computer network of the presentinvention facilitates payments from a payor to a payee without requiringeither consumer to be registered as a merchant. With the help of thefigures, in which like numerals refer to like elements throughout theseveral figures, the detailed description now explains how the computernetwork accomplishes this.

Overview of the Consumer-to-Consumer Payment Process

FIG. 1A illustrates a typical scenario 100A in which aconsumer-to-consumer payment process would be beneficial. The scenario100A depicts a payee (or seller) 130 and a payor (or buyer) 110. Theseller 130 and the buyer 110 have concluded an agreement over theInternet 160. Per this agreement, the seller 130 has promised to shipgoods 150 to the buyer 110. In return, the buyer 110 has promised to paythe seller 130 an amount of money (also called a payment) 140. Theconsumer-to-consumer payment process of the present invention provides aconvenient solution for enabling the buyer 110 and the seller 130 toconsummate the transaction to which they have agreed.

FIG. 1B provides an illustration 100B of the transfer of money in theconsumer-to-consumer payment process. FIG. 1B shows the payor (or buyer)110 and the payee (or seller) 130. An intermediary 120 facilitates thetransfer of money 140 from the buyer 110 to the seller 130. Theintermediary 120 is typically a business that operates theconsumer-to-consumer payment service.

Generally, the responsibilities of the intermediary 120 includecollecting the payment 140 from the buyer 110 and paying the seller 130.For performing this service, the intermediary 120 typically charges afee. The intermediary may collect this fee by paying the seller anamount equal to the buyer's payment to the intermediary minus the fee.

Although the intermediary 120 may receive payment 140 from the buyer 110before the intermediary transfers the payment 140 to the seller 130, theintermediary may choose to pay the seller before receiving payment fromthe buyer. In this case, the intermediary 120 assumes the risk ofnonpayment by the buyer 110. If the intermediary 120 has assumed therisk of nonpayment by the buyer 110 and the buyer does not pay in atimely manner, the intermediary may use the fees collected by offeringthe consumer to consumer payment service to either cover the loss orpursue collection from the buyer.

Instead of assuming the risk of nonpayment in order to pay the seller130 before receiving payment 140 from the buyer 110, the intermediary120 may pay a third party (not shown) that specializes in processingtransactions for the payment instrument chosen by the buyer 110 toassume the risk of nonpayment by the buyer. In this case, theintermediary 120 chooses the third party processor for the third party'sdependability in financial transactions, and the intermediary receives apromise of payment from the third party before the intermediary pays theseller 130. Such a promise of payment from the third party is referredto as an “authorization.”

In the consumer to consumer payment process, the intermediary 120preferably permits the buyer 110 to pay the intermediary through any oneof a variety of different financial instruments. As shown in FIG. 1B,these financial instruments, called payment instruments, may includeflash cash, a credit card, a bank account (which is debited through anelectronic fund transaction), a virtual private payment account (whichis debited through an electronic transaction), or a physical check.

Preferably, the intermediary 120 permits the seller 130 to receivepayment 140 from the intermediary through any one of a variety offinancial instruments. As shown in FIG. 1B, these financial instruments,called disbursement instruments, may include a bank account (which iscredited through an electronic fund transaction), a virtual privatepayment account (which is credited through an electronic transaction),or a physical check. Some financial instruments can be both paymentinstruments and disbursement instruments.

Credit cards, electronic fund transactions for bank accounts, and thehandling of physical checks are well known to those skilled in the art.However, flash cash and virtual payment accounts are not familiar totypical readers. Accordingly, a general description of these twofinancial instruments is now provided.

Flash cash is a payment instrument that enables a payor to executepayment orders over the Internet based on a prearranged cash deposit. Tocreate the flash cash payment instrument, a payor first communicatesover the Internet with a flash cash processor in order to prearrange thecash deposit. The payor then physically visits a location registeredwith the flash cash processor. At the registered location, the payordeposits cash. At a later time, the payor can instruct the flash cashprocessor over the Internet to pay the deposited amount (or a lesseramount) to a payee. The payee's bank account is then automaticallycredited in an electronic fund transaction.

There are many embodiments of a virtual private payment account. Eachembodiment differs in the functionality provided by the virtual privatepayment account. Typically, a virtual private payment account is offeredthrough an online retailer or an Internet service provider (ISP). Theowner of the virtual private payment account may buy items, typicallythrough online transactions, and charge them to the virtual privatepayment account. Because only entities closely associated with theentity offering the virtual private payment account will accept paymentfrom the account, the entity accepting payment from the virtual privatepayment account is typically not charged a processing fee. In essence,the virtual private payment account is like a private label credit card,but no plastic card is issued to the owner of the account.

When a virtual private payment account owner makes a purchase andcharges the purchase to the account, the charge may be covered by apositive balance in the account. The virtual private payment account mayalso be associated with a line of credit, and purchases charged to thevirtual private payment account which result in a negative balance maybe billed to the account owner in periodic statements.

Various options for permitting the creation of positive balances invirtual private payment accounts may exist at the discretion of theentity offering the account. For example, the entity offering thevirtual private payment account may permit a cash deposit to create apositive virtual private payment account balance. Also, the entityoffering the account may permit associated retailers to credit a virtualprivate payment account, possibly for promotional purposes.

Optionally, the entity offering the virtual private payment account mayallow the account owner to receive monetary disbursements equivalent tothe positive account balance. In another embodiment, the entity offeringthe virtual private payment account may allow the account owner toreceive monetary disbursements only for positive account balancescreated through refunds or cash deposits, but not for positive accountbalances created by a retailer for promotional purposes.

Computer Network for Enabling Consumer-to-Consumer Payments

FIG. 2 is a block diagram illustrating an exemplary computer networkarchitecture 200 for providing the consumer to consumer payment service.Each one of the various nodes 210, 220, 230, 240, 250, 270, 275, 280,285, and 290 performs functions in the consumer to consumer paymentprocess that are different than the functions the other computer nodesperform.

Each node of the network 200 may have typical features of a computersystem, such as a processing unit, a system memory containing randomaccess memory (RAM) and read only memory (ROM), and a system bus thatcouples the system memory to the processing unit. The computer may alsoinclude various memory storage devices, such as a hard disk drive, amagnetic disk drive (e.g., to read from or write to a removable magneticdisk), and an optical disk drive (e.g., to read from or write to opticalmedia such as a CD-ROM).

A number of program modules may be stored in the drives and RAM of thecomputer system. Program modules control how the computer systemfunctions and interacts with the user, with input/output devices, orwith other computers. Program modules include routines, an operatingsystem, application program modules, data structures, browsers, andother software or firmware components. The invention may conveniently beimplemented in various program modules that are stored on the computersof the network 200 and implement the methods described in the detaileddescription.

No particular programming language will be described for carrying outthe various procedures described in the detailed description because itis considered that the operations, steps, and procedures described andillustrated in the accompanying drawings are sufficiently disclosed topermit one of ordinary skill in the art to practice an exemplaryembodiment of the present invention. Moreover, there are many computersand operating systems which may be used in practicing an exemplaryembodiment, and therefore no detailed computer program could be providedwhich would be applicable to all of these many different systems. Eachuser of a particular computer will be aware of the language and toolswhich are most useful for that user's needs and purposes.

Likewise, various computer nodes of the network 200 require one or moredatabases for storing information pertinent to that computer's role inconsumer to consumer payment process. In the detailed description, thesedatabases are frequently described with respect to their functionalityor the types of information they store. One skilled in the art shouldrecognize that a variety of different databases and a variety ofdifferent record structures for storing information in those databasesare available for providing the described functionality or storing thedescribed information. Accordingly, details of such databaseimplementations need not be described. Where details of a databaseimplementation are described, the detailed description provides them byway of example, not by way of limitation.

In FIG. 2, the lines connecting the various nodes of the computernetwork 200 illustrate network communication connections. For example,these connections may be Internet connections. Instead, a givenconnection between two computers of the network 200 may be a dedicatedconnection intended to provide a high speed, special purposecommunications link between the two computers. When a first computernode is described as remote to a second computer node, the firstcomputer node and the second computer node are linked by a networkcommunication connection.

One skilled in the art will appreciate that the network practicing anembodiment of the present invention may take various forms. Accordingly,one may use other types of networks and combinations of networkconnections in a given embodiment of the present invention.

Still referring to FIG. 2, the detailed description will describe thefunctionality of the various computer nodes of the computer network 200.The buyer 110 communicates with the computer network 200 through thebuyer computer 220. Likewise, the seller 130 communicates with thecomputer network 200 through the seller computer 210. Preferably, thebuyer computer 220 and the seller computer 210 are connected to thecomputer network 200 through Internet connections. Using HyperTextTransfer Protocol (HTTP), computer nodes 230 and 240 may communicatewith the buyer 110 and the seller 130 through Web pages. To use theseWeb pages, the buyer computer 220 and seller computer 210 typically runan appropriate Web browser.

The described Web pages provide information to the buyer 110 and theseller 130 about the consumer to consumer payment service. Furthermore,these Web pages provide a convenient graphical user interface forreceiving information from the buyer 110 and the seller 130. Forexample, forms, which are well known to those skilled in the art of Webdesign, provide an easy and efficient mechanism for soliciting andreceiving information from the buyer 110 and the seller 130 through Webpages. However, other communication protocols and other graphical userinterfaces are known to those skilled in the art, and therefore thesecommunication alternatives may be used for implementing the presentinvention.

The transaction facilitator 230 may be a Web site that allows two peopleto define a desired transaction. Usually, the transaction facilitator230 also serves to introduce the payor 110 and the payee 130. When thetransaction is for the sale of goods, the payor 110 is referred to as abuyer, and the payee 130 is referred to as a seller.

A typical transaction facilitator 230 is an Internet auction site, suchas EBAY and YAHOO! AUCTION. Generally, such auction sites 230 allow aseller 130 to post an item for sale to potential bidders. Bidders thenplace bids on the posted items, and the high bidder wins the auction,thereby becoming the buyer 110.

Similarly, the transaction facilitator 230 may be an Internetclassifieds site, which allows a seller 130 to post an item for sale ata specified price. The classifieds site 230 then forwards to the seller130 all offers from potential buyers to buy the item at the specifiedprice. The seller 130 can then accept one of the offers to create atransaction. If implemented by the Internet classifieds site 230, apotential buyer may have the opportunity to negotiate the sale price ofthe item with the seller 130.

Often, a transaction facilitator 230 requires users of the serviceoffered by the transaction facilitator to register with the transactionfacilitator. Typically, a user registers to use the transactionfacilitator 230 by providing basic identification information, such asname, e-mail, and password. The transaction facilitator 230 may assignthe person a unique user ID for keeping track of information pertainingto the user. The transaction facilitator 230 may use the user ID as akey to a database record storing the information identifying the userand his transactions. To log into the transaction facilitator 230, theuser may need to provide the user ID and the appropriate password.

Preferably, the transaction facilitator 230 also has a mechanism forstoring information about specific transactions and the buyer 110 andthe seller 130 in those transactions. This may be done through adatabase of transaction records, each identified by a unique transactionID and having fields for storing the buyer user ID, the seller user ID,the transaction amount, and the item.

After the transaction facilitator 230 determines that the buyer 220 andthe seller 210 have agreed upon a transaction, the transactionfacilitator refers the transaction to the consumer to consumer paymentenabler 240 to administer the consumer to consumer payment service.Typically, the intermediary 120 runs the payment enabler 240. Thepayment enabler 240 may offer an application programming interfaceproviding transaction facilitators, such as the transaction facilitator230, with a convenient and standardized means to communicate with thepayment enabler.

When referring a transaction to the payment enabler 240, the transactionfacilitator 230 may automatically pass information about the buyer 110,the seller 130, and their underlying transaction to the payment enabler.The payment enabler 240 then uses this information to administer theconsumer to consumer payment process, thereby facilitating payment fromthe buyer 110 to the seller 130. By automatically passing transactioninformation from the transaction facilitator 230 to the payment enabler240, the consumer to consumer payment service eliminates the need forthe buyer 110 and the seller 130 to provide duplicate information to thepayment enabler 240 that the buyer and seller already provided to thetransaction facilitator when defining their transaction.

Preferably, the transaction facilitator 230 and the payment enabler 240cooperate to implement the consumer to consumer payment service in amanner that prevents the buyer 110 and the seller 130 from realizingthat the transaction facilitation service provided by the transactionfacilitator and the consumer to consumer payment service provided by thepayment enabler are administered by two different computer nodes,possibly run by two different entities. For example, the transactionfacilitator 230 preferably passes the transaction information to thepayment enabler 240 without knowledge of the buyer 110 or the seller130.

When communicating with the buyer 110 and the seller 130 to administerthe consumer to consumer payment process, the payment enabler 240preferably employs Web pages that are branded identically to the Webpages that the transaction facilitator 230 uses when communicating withthe buyer and the seller. In other words, all Web pages provided to thebuyer 110 and the seller 130 by the transaction facilitator 230 and thepayment enabler 240 preferably bear the same trademarks. Alternatively,these Web pages can be co-branded with the trademarks of both the entityrunning the transaction facilitator 230 and the entity running thepayment enabler 240.

Preferably, the payment enabler 240 delegates the responsibility forprocessing transactions for each type of financial instrument to adifferent computer node of the network. Specifically, the flash cashprocessor 285 processes flash cash payments from the buyer 110, thecredit card transaction processor 290 processes credit card paymentsfrom the buyer 110, the electronic fund transaction processor 270processes credits to and debits from bank accounts through electronicfund transactions, the virtual private payment account processor 275processes credits to and debits from virtual private payment accounts,and the check processor 280 processes paper check payments from thebuyer 110 and paper check disbursements to the seller 130. Each of thecomputer nodes 270, 275, 280, 285, and 290, in turn, may interact withother computer nodes (not shown) of the network 200 in order to processa payment from the buyer 110 or a disbursement to the seller 130.

The computer nodes for processing disbursement instruments are calleddisbursement instrument processors 260. The computer nodes forprocessing payment instruments are called payment instrument processors265. All the disbursement instrument processors 260 of the exemplaryembodiment of FIG. 2 are also payment instrument processors 265.

Preferably, each of the payment instrument processors 265 are managed bythird parties willing to grant authorizations based on transactionrequests from the payment enabler 240 for specific dollar amounts. Thepayment instrument processors 265 may handle authorization requests fromthe payment enabler 240 in an automated manner. When a paymentinstrument processor 265 grants an authorization for a specific dollaramount for a specified payment instrument, the managing third partythereby promises payment to the intermediary 120 and assumes the risk ofnonpayment by the buyer 110.

To use the consumer to consumer payment process, the payment enabler 240typically requires the buyer 110 to register a payment instrument andthe seller 130 to register a disbursement instrument. At a minimum,registration of a financial instrument involves the payment enabler 240receiving from the buyer 110 or the seller 130 basic identificationinformation about the financial instrument necessary to make transactionrequests for that instrument to the instrument processor 270, 275, 280,285, or 290. Typically, the payment enabler 240 provides theidentification information received from the consumer to the appropriateprocessor 270, 275, 280, 285, or 290 in order to verify that thefinancial instrument exists.

If the consumer is attempting to register a payment instrument, theappropriate payment instrument processor 265 may also perform additionalbackground checks on the payment instrument to determine if the paymentinstrument processor will accept later authorization requests for thatpayment instrument. Such a background check may, for example, includeverifying that the buyer 110 has completed the flash cash deposit, thebuyer has completed the check deposit, the buyer has not fraudulentlyprovided the credit card, the buyer does not have a history ofoverdrawing the bank account provided, or the virtual private paymentaccount processor has a relationship with the entity offering thevirtual private payment account. These preliminary background checks areintended to be different than authorization requests, which are laterrequests from the payment enabler 240 for a transaction on a financialinstrument for a specific dollar amount at a specific point in time. Thepayment instrument processors 265 need not base these preliminarybackground checks on a consideration of specific amounts. Rather, thepayment instrument processors 265 may base these preliminary backgroundchecks on whether the payment instrument the buyer 110 is attempting toregister is in good standing.

Preferably, the payment enabler 240 permits a given consumer to registerboth as a buyer 110 and as a seller 130. This allows the consumer to usethe consumer to consumer payment service for multiple transactions, insome of which the consumer is a buyer 110 and in some of which theconsumer is a seller 130. Furthermore, the payment enabler 240 maypermit the consumer to register multiple payment instruments andmultiple disbursement instruments. If the payment enabler 240 allowsregistration of multiple financial instruments, the payment enabler 240may permit the consumer to identify a preferred payment instrument and apreferred disbursement instrument. Typically, the consumer can changethe preferred financial instrument at any time before confirming theconsumer's desire to proceed with a given transaction.

After the buyer 110 and the seller 130 have registered a financialinstrument, the payment enabler obtains confirmation from both the buyerand the seller that they wish to proceed with the transaction. Thepayment enabler 240 also requires the buyer 110 to specify the paymentinstrument and the seller 130 to specify the disbursement instrument tobe used. The payment enabler 240 then obtains authorization for payment140 from the buyer 110 from the appropriate payment instrument processor265, and the intermediary 120 receives payment from that paymentinstrument processor in due course.

After receiving authorization for payment 140, the payment enabler 240notifies the appropriate disbursement instrument processor 260 to paythe seller 130 through the disbursement instrument chosen by the seller.The disbursement instrument processor 260 typically does this by drawingon funds in a bank account of the intermediary 120.

In one embodiment, the payment enabler 240 does not pay the seller 130until the seller has delivered acceptable goods to the buyer 110 throughan authorized shipping service. To monitor the status of a pendingshipment, the payment enabler 240 may interface with a shipping servicetracking database 250.

The shipping service tracking database 250 is maintained by the shippingservice the seller 130 uses to ship the goods. When a parcel is sentthrough an authorized shipping service, the shipping service assigns theparcel a tracking number. For each parcel sent using the shippingservice, the shipping service tracking database 250 stores thecorresponding tracking number and delivery status. The shipping servicetracking database 250 is functional for receiving a tracking number andreplying with the status of the parcel corresponding to that trackingnumber.

The payment enabler 240 (or the transaction facilitator 230) may alsoprovide a Web page enabling both the buyer 110 and the seller 130 torequest the status of the parcel used to ship the goods. Once such arequest has been received, the payment enabler 240 uses the trackingnumber to query the shipping service tracking database 250 for thestatus of the delivery. The payment enabler 240, in turn, relays thestatus of the delivery to the buyer 110 or the seller 130 through a Webpage.

One procedure for tracking the shipment of goods requires the seller 130to notify the payment enabler 240 of the tracking number received fromthe shipping service. After the payment enabler 240 receivesauthorization for payment 140, the payment enabler notifies the seller130 to ship the goods to the buyer 110. The seller 130 then ships thegoods to the buyer 110 through an authorized shipping service andobtains a tracking number. The payment enabler 240 requires the seller130 to enter this tracking number into the payment enabler. Using thistracking number, the payment enabler 240, can query the shipping servicetracking database 250 to determine the delivery status of the goods.

Alternatively, the payment enabler 240 may automatically provide theseller 130 with a tracking number to be used for shipping the goods.Upon receiving authorization for the payment 140, the payment enabler240 may query the shipping service tracking database 250 to obtain avalid tracking number. Through a Web page, the payment enabler 240 thennotifies the seller 130 to ship the goods to the buyer 110 using theauthorized shipping service and this predetermined tracking number.Then, the seller 130 delivers the goods to the shipping service alongwith the predetermined tracking number provided by the payment enabler240. The shipping service, in turn, ships the goods using a parcelidentified by the predetermined tracking number and appropriatelymaintains the shipping service tracking database 250. Because thepayment enabler 240 provided the tracking number to the seller 130, thepayment enabler knows the tracking number and can query the shippingservice tracking database 250 for the delivery status of the goods.

Once the payment enabler 240 determines that the goods have beendelivered to the buyer 110, the payment enabler may further determine ifthe goods are acceptable to the buyer 110 before paying the seller 130.The payment enabler 240 may make this determination by providing thebuyer 110 a predetermined amount of time, measured from the date ofdelivery indicated by the shipping service tracking database 250, tonotify the payment enabler of rejection of the goods. If the buyer 110notifies the payment enabler 240 that acceptable goods have beendelivered or the buyer does not reject the goods within a predeterminedtime after the shipping service tracking database 250 indicates that thegoods have been delivered, the payment enabler 240 notifies theappropriate disbursement instrument processor 260 to pay the seller 130through the disbursement instrument chosen by the seller.

One skilled in the art will appreciate that the present invention is notlimited to the computer network architecture 200 of FIG. 2.Specifically, the functions described for the various computer nodes ofFIG. 2 could be distributed differently. For instance, the functions ofthe payment enabler 240 and the transaction facilitator 230 could becombined into a single computer node. Similarly, the payment enabler 240could incorporate the functions of any of the payment instrumentprocessors 265 or disbursement instrument processors 260. Although eachof computer nodes 270, 275, and 280 perform both payment functions anddisbursement functions for a given type of financial instrument, twodifferent computer nodes could perform the payment functions and thedisbursement functions for a given type of financial instrument.Furthermore, an existing merchant credit card processing system could bemodified to incorporate functions of the payment enabler 240 and thecredit card transaction processor 290, thereby enabling consumer toconsumer payments through credit cards.

Flow Charts for the Consumer-to-Consumer Payment Process

FIG. 3 shows the steps of an exemplary consumer-to-consumer paymentprocess 300. The process 300 begins with step 310, in which interactionbetween the buyer 110 and the seller 130 through the transactionfacilitator 230 results in an agreed upon transaction for the sale ofgoods. The transaction facilitator 230 may, for example, be an onlineauction site, an online classifieds site, or any site which allows theseller 130 to sell goods to the buyer 110 without requiring that theseller 130 be registered as a merchant. Preferably, the transactionfacilitator 230 automatically passes the transaction details to thepayment enabler 240.

In step 320, the buyer 110 registers at least one payment instrumentwith the payment enabler 240. FIGS. 4A, 4B, 4C, 4D, and 4E describe theregistration process for the various payment instruments available tothe buyer 110.

In step 330, the seller 130 registers at least one disbursementinstrument with the payment enabler 240. FIGS. 5A, 5B, and 5C describethe registration process for the various disbursement instrumentsavailable to the seller 130.

In step 340, the seller 130 selects a disbursement instrument that theseller has previously registered. The seller 130 then instructs thepayment enabler 240 to disburse money due from the buyer 110 through theselected instrument.

In step 350, the buyer 110 selects a payment instrument that the buyer110 has previously registered. The buyer 110 then instructs the paymentenabler 240 to pay the seller 130 using the selected instrument.

In step 360, the payment enabler 240 ensures completion of thetransaction between the buyer 110 and the seller 130. The process 300then ends in step 370.

FIG. 4A is a logical flow diagram illustrating the steps in an exemplaryprocess for the registration of a flash cash deposit as a paymentinstrument. The buyer 110 may follow this routine in step 320 of FIG. 3.

The routine begins at step 410A, in which the payment enabler 240presents the buyer 110 with a graphical user interface enabling thebuyer 110 to enter a deposit amount and information identifying thebuyer. In step 420A, the buyer 110 enters the requested informationthrough the graphical user interface.

In step 430A, the payment enabler 240 creates a registration record forthe flash cash deposit in a registration database stored by the paymentenabler 240. The registration record for the flash cash deposit storesidentification information for the flash cash deposit instrument andindicates when the buyer 110 has made the cash deposit in order tocomplete registration of the flash cash instrument.

In step 440A, the payment enabler 240 stores a flag in the registrationrecord to indicate that buyer 110 has not yet made the deposit. In step450A, the payment enabler 240 provides the flash cash processor 285 withidentification information for the buyer 110 and the deposit amount. Theflash cash processor 285 stores this information in its own database.

In step 460A, the buyer 110 physically goes to a deposit locationregistered with the flash cash processor 285. At the deposit location,the buyer 1110 deposits cash in the amount previously specified whensetting up the deposit with the payment enabler 240.

In step 470A, the deposit location electronically notifies the flashcash processor 285 that the buyer 110 has completed the prearrangeddeposit. In step 480A, the flash cash processor 285 notifies the paymentenabler 240 that the buyer 110 has completed the prearranged deposit.

Upon notification that the buyer 110 has completed the prearrangeddeposit, in step 490A, the payment enabler 240 updates the flag in theregistration record to indicate that the buyer 110 has completed thedeposit. The routine then returns in step 495A.

FIG. 4B is a logical flow diagram illustrating the steps in an exemplaryprocedure for the registration of a credit card as a payment instrument.The buyer 110 may follow this routine in step 320 of FIG. 3.

The routine begins with step 410B, in which the payment enabler 240presents the buyer 110 with a graphical user interface enabling thebuyer 110 to enter credit card registration information. In step 420B,the buyer 110 enters his name, address, card association, card number,and card expiration date through the graphical user interface.

In step 430B, the payment enabler 240 provides the information enteredby the buyer 110 to the credit card transaction processor 290 forregistration processing. In step 440B, the credit card transactionprocessor 290 compares the address provided by the payment enabler 240to the address of record for the credit card holder. Instead ofperforming the address verification comparison at the credit cardtransaction processor 290, the credit card transaction processor mayforward the registration information entered by the buyer 110 to thecredit card issuer, which performs the address comparison and reportsthe results of the comparison back to the credit card transactionprocessor.

In step 450B, the credit card transaction processor 290 sends thepayment enabler 240 a score indicating the degree to which the addressprovided by the payment enabler 240 and the address of record match.Such address matching analyses are known to those skilled in the art.

In step 460B, the payment enabler 240 determines if the address matchingscore meets minimum requirements for registration. If the score does notmeet the minimum requirements for registration, the “NO” branch isfollowed to step 480B. In step 480B, registration of the credit card isdenied, and the routine returns in step 490B.

Referring again to step 460B, if the score does meet minimumrequirements for registration, then the “YES” branch is followed to step470B. In step 470B, the payment enabler 240 creates a registrationrecord for the credit card. The registration record is stored in aregistration database at the payment enabler 240. The routine thenreturns in step 490B.

FIG. 4C is a logical flow diagram illustrating the steps in an exemplaryprocess for registration of a bank account as a payment instrument viaelectronic fund transactions. The buyer 110 may follow this routine instep 320 of FIG. 3.

The routine begins with step 410C, in which the payment enabler 240presents the buyer 110 with the graphical user interface enabling thebuyer 110 to enter bank account registration information. In step 420C,the buyer 110 enters his name. The buyer 110 also enters the routingnumber and account number for the bank account the buyer 110 wishes toregister.

In step 430C, the payment enabler 240 provides information entered bythe buyer 110 to the electronic fund transaction processor 270 forregistration processing. In step 440C, the electronic fund transactionprocessor 270 processes the registration information by reviewing anegative history database to determine if there is negative history forthe account. Such a negative history review is known to those skilled inthe art.

In step 450C, the electronic fund transaction processor 270 determinesif significant negative history has been found. If significant negativehistory has been found, the “YES” branch is followed to step 480C, andregistration of the bank account as a payment instrument is denied. Inthis case, the routine returns in step 490C.

Referring again to step 450C, if significant negative history is notfound, then the “NO” branch is followed to step 460C. In step 460C, theelectronic fund transaction processor 270 notifies the payment enabler240 that transaction requests will be accepted for the bank account.

In step 470C, the payment enabler 240 creates a registration recordindicating that the bank account has been registered for debiting inelectronic fund transactions. This registration record is stored in aregistration database at the payment enabler 240. The routine thenreturns in step 490C.

FIG. 4D is a logical flow diagram illustrating the steps in an exemplaryprocess for the registration of a virtual private payment account as apayment instrument. The buyer 110 may follow this routine in step 320 ofFIG. 3.

The routine begins in step 410D, in which the payment enabler 240presents the buyer 110 with a graphical user interface enabling thebuyer 110 to enter the virtual private payment account registrationinformation. In step 420D, the buyer 110 enters the account provider andthe account number for the virtual private payment account. The buyer110 enters this information through the graphical user interfacepresented to the buyer in step 410D.

In step 430D, the payment enabler 240 determines if the account providerhas been approved by the payment enabler 240. If the account providerhas not been approved by the payment enabler 240, then the “NO” branchis followed to step 470D, in which registration of the virtual privatepayment account as a payment instrument is denied. In that case, theroutine returns in step 480D.

Referring again to step 430D, if the payment enabler 240 determines thatthe account provider has been approved by the payment enabler 240, thenthe “YES” branch is followed to step 440D. In step 440D, the paymentenabler 240 queries the virtual private payment account processor 275 ofthe account provider to determine if the processor will accept requestsfor debiting the virtual private payment account. The virtual privatepayment account processor 275, in response, notifies the payment enabler240 if such requests will be accepted.

In step 450D, the payment enabler 240 determines if these requests willbe accepted. If requests for debiting the virtual private paymentaccount will not be accepted, then the “NO” branch is followed to step470D, in which registration of the virtual private payment account is apayment instrument is denied. The routine then returns in step 480D.

Referring again to step 450D, if the payment enabler 240 is told by thevirtual private payment account processor 275 that requests for debitingthe virtual private payment account will be accepted, then the “YES”branch is followed to step 460D. In step 460D, the payment enabler 240creates a registration record that indicates that the virtual privatepayment account has been registered for debiting. The payment enabler240 stores this registration record in a registration database at thepayment enabler 240. The routine then returns in step 480D.

FIG. 4E is a logical flow diagram illustrating the steps in an exemplaryprocess for the registration of a physical check as a paymentinstrument. The buyer 110 may follow this routine in step 320 of FIG. 3.

In step 410E, the payment enabler 240 presents the buyer 110 with thegraphical user interface enabling the buyer 110 to enter identificationinformation and a check amount. In step 420E, the buyer 110 enters therequested information through the graphical user interface.

In step 430E, the payment enabler 240 creates a registration record forthe check deposit in a registration database stored by the paymentenabler 240. In step 440E, the payment enabler 240 stores a flag in theregistration record to indicate that the buyer 110 has not yet made thecheck deposit.

In step 450E, the payment enabler 240 provides the check processor 280with identification information for the buyer 110 and the check depositamount. The check processor 280 stores this information and awaitsreceipt of the check from the buyer 110.

In step 460E, the buyer 110 sends a physical check to an addressspecified by the check processor 280. In step 470E, the check arrives atthe address specified by the check processor 280. The check processor280 processes the check and obtains the payment specified by the check.

In step 480E, the check processor 280 electronically notifies thepayment enabler 240 that the buyer 110 has completed the prearrangedcheck deposit. In step 490E, the payment enabler 240 updates the flag inthe registration record to indicate that the buyer 110 has completed thecheck deposit. The routine then returns in step 495E.

FIG. 5A is a logical flow diagram illustrating the steps in an exemplaryprocess for the registration of a bank account as a disbursementinstrument via electronic fund transactions. The seller 130 may followthis routine in step 330 of FIG. 3.

In step 510A, the payment enabler 240 presents the seller 130 with agraphical user interface enabling the seller 130 to enter bank accountregistration information. In step 520A, the seller 130 enters theseller's name. The seller 130 also enters the routing number and accountnumber for the bank account. The seller 130 enters this informationthrough the graphical user interface presented to the seller in step510A.

In step 530A, the payment enabler 240 provides the information enteredby the seller 130 to the electronic fund transaction processor 270 forregistration processing. In step 540A, the electronic fund transactionprocessor 270 verifies the existence of the account and notifies thepayment enabler 240 if the account exists.

In step 550A, the payment enabler 240 determines if the payment enablerwas notified that the account was found. If the account was not found,then the “NO” branch is followed to step 580A, and registration of thebank account as a disbursement instrument is denied. The routine thenreturns in step 590A.

Referring again to step 550A, if the bank account was found, then the“YES” branch is followed to step 560A. In step 560A, the electronic fundtransaction processor 270 notifies the payment enabler 240 that theelectronic fund transaction requests will be accepted for the bankaccount.

In step 570A, the payment enabler 240 creates a registration recordindicating that the bank account has been registered for crediting inelectronic fund transactions. This registration record is stored in thedatabase at the payment enabler 240. The routine then returns in step590A.

FIG. 5B is a logical flow diagram illustrating the steps in an exemplaryprocess for registration of a virtual private payment account as adisbursement instrument. The seller 130 may follow this routine in step330 of FIG. 3.

The routine begins in step 510B, in which the payment enabler 240presents the seller 130 with a graphical user interface enabling theseller 130 to enter the virtual private payment account registrationinformation. In step 520B, the seller 130 enters the account providerand the account number for the virtual private payment account. Theseller 130 enters this information through the graphical user interfacepresented to the seller in step 510B.

In step 530B, the payment enabler 240 determines if the account providerentered by the seller 130 has been approved by the payment enabler 240.If the account provider has not been approved by the payment enabler240, then the “NO” branch is followed to step 550B. In step 550B,registration of the virtual private payment account as a paymentinstrument is denied. The procedure then returns in step 560B.

Referring again to step 530B, if the account provider has been approvedby the payment enabler 240, then the “YES” branch is followed to step540B. In step 540B, the payment enabler 240 creates a registrationrecord indicating that the virtual private payment account has beenregistered for crediting. The registration record is stored in adatabase at the payment enabler 240. The routine then returns in step560B.

FIG. 5C is a logical flow diagram illustrating the steps in an exemplaryprocess for registration of a mailed check as the disbursementinstrument. The seller 130 may follow this routine in step 330 of FIG.3.

The routine begins in step 510C, in which the payment enabler 240presents the seller 130 with a graphical user interface enabling theseller 130 to enter registration information for receiving disbursementsthrough a mailed check. In step 520C, the seller 130 uses the graphicaluser interface to enter the seller's name and the address to which theseller wants the check processor 280 to mail disbursement checks.

In order to register to receive a mailed check disbursement instrument,the payment enabler 240 also requires that the seller 130 register acredit card. Registration of a credit card provides protection to theintermediary 120 because the payment enabler 240 can charge the creditcard in order to refund the buyer 110 should the seller 130 cash thedisbursement check and disappear in a fraudulent transaction. The creditcard can also be used to refund the buyer 110 in the event of achargeback. Thus, in step 530C, the payment enabler 240 requires theseller 130 to enter credit card information, including the cardassociation of the credit card, the card number, and the card expirationdate. The seller 130 enters this information through a graphical userinterface provided by the payment enabler 240.

In step 540C, the payment enabler 240 provides the information enteredby the seller 130 to the credit card transaction processor 290 forregistration processing. In step 550C, the credit card transactionprocessor 290 compares the address provided by the payment enabler 240to the address of record for the credit card holder. Instead ofperforming the address verification comparison at the credit cardtransaction processor 290, the credit card transaction processor mayforward the registration information entered by the buyer 110 to thecredit card issuer, which performs the address comparison and reportsthe results of the comparison back to the credit card transactionprocessor. In step 560C, the credit card transaction processor 290 sendsthe payment enabler 240 a score indicating the degree to which theaddress provided by the payment enabler 240 matches the address ofrecord for the credit card holder.

In step 570C, the payment enabler 240 determines if the score meetsminimum requirements for registration of the credit card. If the scoredoes not meet the minimum requirements for registration, then the “NO”branch is followed to step 590C, and the payment enabler 240 tells theseller 130 that the seller cannot register to receive disbursementsthrough mailed checks until the seller provides a valid credit card witha matching address. The routine then returns in step 595C.

Referring again to step 570C, if the score returned by the credit cardtransaction processor 290 does meet minimum requirements for credit cardregistration, then the “YES” branch is followed to step 580C. In step580C, the payment enabler 240 creates a registration record thatindicates that the seller 130 can receive mailed check disbursements.This record includes the address to which the check disbursement shouldbe mailed, as well as the credit card information needed to protectagainst fraud and to enable chargebacks. This registration record isstored in a database at the payment enabler 240. The routine thenreturns in step 595C.

FIG. 6 is a logical flow diagram illustrating exemplary steps forcompleting routine 360 on FIG. 3. Routine 360 also appears on FIGS. 9,10 and 11. The routine 360 contains exemplary steps that the paymentenabler 240 can follow to ensure completion of the transaction betweenthe buyer 110 and the seller 130.

Routine 360 begins with step 610. In step 610, the payment enabler 240seeks an authorization for payment of the amount buyer 110 owes seller130. The payment enabler 240 seeks this authorization from the paymentinstrument processor 265 associated with the payment instrument selectedby the buyer 110. The payment enabler 240 notifies the paymentinstrument processor 265 that the recipient of the authorized paymentshould be a bank account of the intermediary 120.

Generally, authorization refers to the point at which the paymentenabler 240 passes the risk of non-payment by the buyer 110 to theentity running the payment instrument processor 265 from whichauthorization is sought. For flash cash, authorization is defined atwhich the flash cash processor 285 notifies the payment enabler 240 thatthe buyer 110 has completed the prearranged deposit in step 480A of FIG.4A. Thus, for flash cash, authorization automatically occurs during theregistration process of FIG. 4A. Similarly, authorization for a physicalcheck occurs automatically during the registration process of FIG. 4E instep 480E, in which the check processor 280 electronically notifies thepayment enabler 240 that the buyer 110 has completed the prearrangedcheck deposit. This is true even though the bank account of theintermediary 120 may not yet have received the associated payment.

For a credit card transaction, the authorization process is wellunderstood by those skilled in the art. Specifically, the paymentenabler 240 provides a payment request to the credit card transactionprocessor 290. This charge request includes the payment amount and thecredit card information. In the manner known to those skilled in theart, the credit card transaction processor 290 determines whether or notto accept this charge, a decision typically based on the credit card'sspending limit, the card's current balance, and the amount of theauthorization request. If the charge is accepted by the credit cardtransaction processor 290, the credit card transaction processor 290generates an authorization number, which the credit card transactionprocessor 290 provides to the payment enabler 240. Upon authorization,the intermediary 120 is assured payment, and the risk of loss has passedto the credit card transaction processor 290.

For payment by the buyer 110 through an electronic fund transaction, anauthorization is also obtained through methods known to those skilled inthe art. Specifically, the payment enabler 240 makes an electronic fundtransaction request of the electronic fund transaction processor 270.This transaction request includes the dollar amount, as well as therouting number and the account number of the account to be debited. Theelectronic fund transaction processor 270 determines whether to grantthe authorization based upon a number of factors, including the dollaramount of the debit request and the current account balance. If theelectronic fund transaction processor 270 grants the authorization, theelectronic fund transaction processor 270 assumes the risk ofnon-payment by the buyer 110 and notifies the payment enabler 240 thatauthorization is granted.

Authorization for a debiting of a virtual private payment account mayoccur in a manner analogous to debiting a bank account in an electronicfund transaction.

The payment enabler 240 may provide the buyer 110 with a predeterminednumber of attempts to obtain an authorization. Different attempts may bewith the same instrument, or the different attempts may be withdifferent instruments.

In step 620, the payment enabler 240 determines if an authorization wasobtained for the payment instrument selected by the buyer 110. Ifauthorization was not obtained, then the “NO” branch is followed to step680, and the routine returns. If, in step 620, authorization wasobtained, then the “YES” branch is followed to step 630.

Once authorization has been obtained, the intermediary 120 is assuredpayment because the payment enabler 240 has passed to another party therisk of non-payment by the buyer 110. Thus, the intermediary 120 obtainsthe amount due automatically at a later time. In step 630, the bankaccount of the intermediary 120 receives deposit of the amountauthorized for the payment instrument. However, in the case of atransfer of money from a virtual private payment account of the buyer110 to a virtual private payment account of the seller 130, the moneyneed not pass through a bank account of the intermediary 120, but rathercan occur directly at the request of the payment enabler 240.

The collection of money from the buyer 110 and the transfer of thatmoney to the bank account of the intermediary 120 occurs in the mannerknown to those skilled in the art. In the case of flash cash, the flashcash processor 285 coordinates a direct deposit into the bank account ofthe intermediary 120. The credit card transaction processor 290coordinates settlement in the typical way for credit cards. Theelectronic fund transaction processor 270 uses the automated clearinghouse to accomplish settlement. The virtual private payment accountprocessor 275 generates settlement by debiting the virtual privatepayment account of the buyer 110 and generating a direct deposit intothe bank account of the intermediary 120. The check processor 280 mayalso generate a direct deposit into the bank account of the intermediary120 to remit payment to the intermediary 120.

In step 640, the payment enabler 240 verifies delivery of acceptablegoods to the buyer 110. In step 650, the payment enabler 240 determinesif the seller has delivered acceptable goods to the buyer 110. Ifacceptable goods have been delivered, then the “YES” branch is followedto step 670, in which the payment enabler 240 transfers the amount buyer110 owes seller 130 from a bank account of the intermediary 120 to theseller through the disbursement instrument selected by the seller 130.The routine then returns in step 680.

The disbursement transfer in step 670 is accomplished in the mannerknown to those skilled in the art. For example, in the case of anelectronic fund transaction, the payment enabler 240 generates a requestto the electronic fund transaction processor 270 to credit the bankaccount of the seller 130 and debit the account of the intermediary 120.The electronic fund transaction processor 270 processes this requestthrough the automated clearing house. In the case of a virtual privatepayment account selected as the disbursement instrument, the paymentenabler 240 draws funds from the account of the intermediary 120 inorder to pay the virtual private payment account host, which credits thevirtual private payment account of seller 130. In the case of a physicalcheck chosen as the disbursement instrument, the payment enabler 240instructs the check processor 280 to cut a check drawn on a bank accountof the intermediary 120.

Referring again to step 650, if the payment enabler 240 determines thatacceptable goods have not been delivered, then the “NO” branch isfollowed to step 660. In step 660, the payment enabler 240 refunds themoney to the buyer 110, possibly contingent upon the return of theunacceptable goods to the seller 130. The routine then returns in step680.

FIG. 7 is a logical flow diagram illustrating exemplary steps forcompleting routine 640 on FIG. 6. In routine 640, the payment enabler240 verifies the delivery of acceptable goods to the buyer 110.

The routine 640 begins with step 710, in which the payment enabler 240notifies the seller 130 that payment is guaranteed upon receipt andacceptance of goods by the buyer 110. In step 720, the payment enabler240 instructs the seller 130 to ship the goods to the buyer 110 via anapproved shipping service.

In step 730, the seller 130 ships the goods through an approved shippingservice that provides the seller with a tracking number for trackingdelivery of the goods. In step 740, the seller 130 notifies the paymentenabler 240 of the tracking number through a graphical user interfaceprovided by the payment enabler. The payment enabler 240 then storesthis tracking number.

The payment enabler 240 also provides an interface to both the buyer 110and seller 130 that permits them to track the delivery of the goodsthrough the shipping service. To get this information, the paymentenabler 240 queries the shipping service tracking database 250 using thetracking number.

In step 750, the payment enabler 240 periodically queries the shippingservice tracking database 250 until the database indicates a date ofdelivery of the goods to the buyer 110. Alternatively, the paymentenabler 240 could register with the shipping service tracking database250 so that the shipping service tracking database 250 can automaticallynotify the payment enabler 240 when the goods have been delivered to thebuyer 110.

When using the consumer-to-consumer service of the payment enabler 240,the buyer 110 is informed that he should inform the payment enabler ofhis acceptance or rejection of the goods upon delivery. The buyer 110 isalso warned that the goods will be deemed acceptable if the buyer 110registers neither an acceptance nor a rejection of the goods within apredetermined amount of time of the delivery date. In step 760, thepayment enabler 240 determines if the buyer 110 has notified the paymentenabler 240 of rejection of the goods within a predetermined amount oftime of the delivery date. If so, the “YES” branch is followed to step770, in which the payment enabler 240 determines that acceptable goodshave not been delivered. The routine then returns in step 790.

Referring again to step 760, if the payment enabler 240 determines thatthe buyer 110 has not notified the payment enabler of the rejection ofgood within a predetermined amount of time of the delivery date, thenthe “NO” branch is followed to step 780, in which the payment enabler240 determines that acceptable goods have been delivered. In this case,the buyer 110 has notified the payment enabler 240 of the acceptance ofgoods through a graphical user interface or the buyer has failed toreject the goods within the predetermined time period. The routine thenreturns in step 790.

FIG. 8 is a logical flow diagram illustrating exemplary steps completedby routine 660 on FIG. 6. The routine 660 provides exemplary steps thepayment enabler 240 can follow to refund money to the buyer 110 who hasrejected the goods delivered by the seller.

The routine 660 begins with step 810, in which the payment enabler 240notifies the seller 130 that the buyer 110 has rejected the goods. Instep 820, the payment enabler 240 instructs the buyer 110 to ship thegoods back to the seller 130 via an approved shipping service.

In step 830, the buyer 110 ships the goods via an approved shippingservice that provides the buyer 110 with a tracking number for trackingdelivery of the goods. In step 840, the buyer 110 notifies the paymentenabler 240 of the tracking number, allowing both buyer 110 and seller130 to track delivery of the returned goods through a graphical userinterface.

In step 850, the payment enabler 240 periodically queries the shippingservice tracking database 250 until the tracking database 250 indicatesa date of delivery. In step 860, the payment enabler 240 determines ifthe seller 130 has notified the payment enabler of rejection of thereturned goods within a predetermined amount of the time of the deliverydate. If so, the “YES” branch is followed to step 870, and the paymentenabler 240 refuses to make any further transfer of the money until thedispute is resolved. The routine then returns to step 890.

Referring again to step 860, if the seller 130 has not notified thepayment enabler 240 of rejection of the goods within a predeterminedamount of the time of the delivery date, then the “NO” branch isfollowed to step 880. In step 880, the payment enabler 240 refunds themoney to the buyer 110, less the charge for the consumer-to-consumerpayment service. The routine then returns in step 890.

Consumer-to-Consumer Payments in an Auction Environment

FIG. 9 is a logical flow diagram illustrating exemplary steps in anauction process 900 that includes consumer-to-consumer paymentsfacilitated by the payment enabler 240. The process includes staticregistration of the buyer 110 and the seller 130 with the paymentenabler 240.

The auction process may occur through any of the Web auction sites thatare well-known to users of the Internet. A Web auction site, such asEBAY or YAHOO! AUCTION, allows a seller 130 to post an object for saleon the Web site. Numerous bidders then bid on the item on the Web site,leading to a single winning bidder, who becomes the buyer 110.

Static registration occurs when both the buyer 110 and the seller 130register their financial instruments with the payment enabler 240 priorto the bidding process. In contrast, dynamic registration occurs whenthe buyer 110, the seller 130, or both the buyer 110 and the seller 130register with the payment enabler 240 after the bidding process.

Registration with the payment enabler 240 need not be tied to anyparticular auction item. The registration process also need not belimited to registering a particular consumer as a buyer 110 or a seller130. Specifically, any consumer registering with the payment enabler 240may register to be a buyer 110, a seller 130, or both a buyer 110 and aseller 130, so long as the consumer registers appropriate payment ordisbursement instruments. During registration, the consumer may registermultiple payment instruments and multiple disbursement instruments. Theconsumer may also pick a preferred disbursement instrument and apreferred payment instrument, which the consumer can change whendirecting the payment enabler 240 to proceed with a specifictransaction.

The auction process 900 begins with step 910, in which the buyer 110 andseller 130 separately register for participation in a Web-based auctionsite, which is the transaction facilitator 230 of FIG. 2. Registrationwith the auction site 230 is different from registration with thepayment enabler 240 because registration simply enables the buyer 110and seller 130 to participate in online auctions; no payment ordisbursement instruments need to be registered at this point. Uponregistration with the auction site, both the buyer 110 and the seller130 receive a unique user ID from the auction site. This user IDidentifies the buyer 110 and the seller 130 in any transactions in whichthey participate.

In step 920, the buyer 110 registers with the payment enabler 240 byspecifying payment instruments. Typically, the buyer 110 is transferredto the registration Web page of the payment enabler 240 either bychoosing a menu option that appears when the buyer logs onto the auctionsite 230 or by clicking on a hyperlink in an e-mail promoting theconsumer-to-consumer payment service. Preferably, the Web page providedby the payment enabler 240 is branded identically with the auction site230. Furthermore, the auction site 230 preferably passes the buyer userID to the payment enabler 240 for use as the registration record key. Byautomatically passing this buyer user ID from the auction site 230 tothe payment enabler 240, the payment enabler and the auction site canpresent an integrated experience to the buyer 110 in which the buyernever realizes he is at a different site.

In step 930, the seller 130 registers with the payment enabler 240 byspecifying disbursement instruments. Typically, the seller 130 istransferred to the registration Web page of the payment enabler 240either by choosing a menu option that appears when the seller logs ontothe auction site 230 or by clicking on a hyperlink in an e-mailpromoting the consumer-to-consumer payment service. Preferably, the Webpage provided by the payment enabler 240 is branded identically with theauction site 230. Furthermore, the auction site 230 preferably passesthe seller user ID to the payment enabler 240 for use as theregistration record key. By automatically passing this seller user IDfrom the auction site 230 to the payment enabler 240, the paymentenabler and the auction site can present an integrated experience to theseller 130 in which the seller never realizes he is at a different site.

In step 940, the bidding process occurs, and the buyer 110 wins thebidding process for the item (goods) of the seller 130. At this point,the auction site 230 assigns a unique transaction ID for use as a key toa record storing the transaction details. These transactions detailsinclude the item, the price, and the identification of the buyer 110 andthe seller 130 through the buyer user ID and the seller user ID.

In step 950, the buyer 110 notifies the auction site of the desire ofthe buyer 110 to pay the seller 130 through the services of the paymentenabler 240. The buyer 110 may be transferred to a Web page forperforming this notification by clicking on a hyperlink in an e-mailnotifying the buyer of his winning bid. Alternatively, the buyer 110 maydiscover he was the winning bidder by perusing recent transactions afterlogging onto the auction site 230, and the buyer may then choose a menuhyperlink to a Web page for notifying the auction site of a desire touse the consumer-to-consumer payment service.

In step 960, the auction site provides the transaction details to thepayment enabler 240, which stores the information in a database. Thesedetails may include the transaction ID so that the auction site and thepayment enabler 240 can communicate about the particular transaction.

Upon notification that the buyer 110 desires to pay the seller 130through the services of the payment enabler 240, the seller selects aregistered disbursement instrument in step 970. The seller 130 alsocreates an electronic invoice for the transaction through a Web pageprovided by the payment enabler 240. This invoice may include the bidprice, the shipping charges, the handling charges, and the total price.Handling charges may be those fees charged by the payment enabler 240for use of the consumer-to-consumer payment service.

The buyer 110 then learns from perusing his account or reading an e-mailthat the invoice has been created. By clicking on a hyperlink in thee-mail or by navigating appropriately through the interface provided bythe auction site 230, the buyer 110 directs his browser to theelectronic invoice Web page of the payment enabler 240. In step 980, thebuyer 110 reviews this invoice.

The buyer 110 may disagree with the terms stated in the invoice. Forexample, the buyer 110 may disagree with the shipping charges. If thatis the case, there may be an opportunity for the buyer 110 to negotiatethe terms stated in the invoice through electronic messages, sent eitherin e-mail form or through a Web site provided by the payment enabler240, with the seller 130.

In step 990, the buyer 110 selects a registered payment instrument. Bydoing so, the buyer 110 also instructs the payment enabler 240 to paythe seller 130 using the selected instrument.

In step 360, the payment enabler 240 ensures completion of thetransaction between the buyer 110 and the seller 130. The process 900then ends in step 995.

FIG. 10 is a logical flow diagram illustrating the steps of an exemplaryauction process 1000 that incorporates dynamic registration of the buyer110 with the payment enabler 240. Auction process 1000 of FIG. 10 issimilar to the auction process 900 of FIG. 9, except that in the auctionprocess 1000, the buyer 110 registers with the payment enabler 240 afterthe bidding process, instead of before the bidding process.

Specifically, after the buyer 110 notifies the auction site in step 950that the buyer wishes to pay the seller 130 through the payment enabler240, the auction site in step 1010 then redirects the buyer's browser tothe registration page of the payment enabler 240 so that the buyer canregister. At that point, in step 920, the buyer 110 registers with thepayment enabler 240 through an identically branded Web page provided bythe payment enabler 240. After step 920, the auction process 1000proceeds as in the auction process 900 of FIG. 9.

FIG. 11 is a logical flow diagram illustrating the steps of an exemplaryauction process 1100 that incorporates dynamic registration of theseller 130 with the payment enabler 240. Again, the auction process 1100of FIG. 11 is similar to the auction process 900 of FIG. 9, except thatin the auction process 1100, the seller 130 registers with the paymentenabler 240 after the bidding process, instead of before the biddingprocess.

Specifically, the buyer 110 wins the bidding in step 940. In step 950,the buyer 110 notifies the auction site of the buyer's desire to pay theseller 130 through the payment enabler 240. Then, in step 1110, theauction site 230 enables the buyer 110 to request that the seller 130register with the payment enabler 240, because the seller 130 has notyet registered a disbursement instrument for receiving the buyer'spayment. To notify the seller 130 of the request for registration by thebuyer 110, the payment enabler 240 may send the seller an e-mail. Theseller then registers with the payment enabler 240 in step 930.Subsequently, the auction process 1100 proceeds as in the auctionprocess 900 of FIG. 9.

Therefore, a method for offering a consumer to consumer payment serviceover a computer network has been described. Other alternativeembodiments will become apparent to those skilled in the art to which anexemplary embodiment pertains without departing from its spirit andscope. Accordingly, the scope of the present invention is defined by theappended claims rather than the foregoing description.

Personal Merchant Accounts

The consumer-to-consumer payment process 300 can be modified to providea personal merchant account to an individual consumer. These personalmerchant accounts may be managed by the payment enabler 240. Generally,a personal merchant account allows an individual seller 130 to createand manage an online cash register. Once the seller 130 has created theonline cash register, any given buyer 110 may use the online cashregister to pay the seller 130 for goods through any one of a variety ofpayment instrument types the seller has chosen to offer through theonline cash register. In a typical embodiment, the online cash registeris a Web page form for receiving payment instrument information.

The online cash register that the seller 130 creates through theseller's personal merchant account can facilitate transactions betweenthe seller and multiple buyers. The personal merchant account can alsoprovide the seller 130 with tools for managing these multipletransactions. Specifically, the personal merchant account may providethe seller with online backroom capabilities. Typically, the paymentenabler 240 provides these backroom capabilities to the seller 130through graphical user interfaces, such as Web pages.

These backroom capabilities enable the seller 130 to view informationabout all completed transactions for which the seller has been paid andall pending transactions for which the seller has not yet been paid.Also, the backroom capabilities may enable the seller 130 to view orderswhich the seller 130 needs to fulfill for customers. These backroomcapabilities may further provide the seller 130 with tools formonitoring shipments of goods to the various buyers. Furthermore, thebackroom capabilities may calculate the total revenues collected by theseller 130 through the online cash register. Other backroomcapabilities, which are known to those skilled in the art, may beavailable through the personal merchant account.

Typically, the personal merchant account and the online cash registerare integrated with the transaction facilitator 230. The transactionfacilitator 230 may, for example, be an online auction site, an onlineclassifieds site, or an online shopping mall at which the seller 130 hasa virtual storefront for selling a variety of goods. Thus, the seller130 may be referred to the payment enabler 240 for creation of thepersonal merchant account and the online cash register by thetransaction facilitator 230. Similarly, the seller 130 may access thebackroom capabilities of the seller's personal merchant account througha link from the transaction facilitator 230. Upon facilitating anagreement for the sale of goods from the seller 130 to the buyer 110,the transaction facilitator 230 may automatically send the buyer to theseller's online cash register in order to pay.

To create an online cash register, the seller 130 first determines whatpayment methods the seller wishes to offer through the online cashregister. Typically, the seller 130 can select payment instrument typesfrom a graphical user interface provided by the payment enabler 240. Foreach payment instrument type selected by the seller 130, the paymentenabler 240 usually requires the seller to undergo an approval orunderwriting process.

When creating the online cash register, the seller 130 also registers adisbursement instrument for receiving payment from the buyer 110. Theprocedure for registering a disbursement instrument may be analogous toany of the disbursement instrument registration procedures of FIGS.5A–5C.

When creating the online cash register, the seller 130 typically alsodefines additional charges to be added to the price at which the selleragreed to sell goods to the buyer 110. Such additional charges mayinclude sales tax, shipping charges, and handling charges (i.e., themoney the payment enabler 240 charges for processing the payment of thebuyer 110). Once the seller 130 has defined these additional charges,the online cash register automatically calculates these additionalcharges and a total price that includes the sale price of the goods plusthe additional charges. The online cash register then presents a displayof the sale price of the goods, the additional charges, and the totalprice to the buyer 110 for payment.

The additional charges may be predefined by the seller 130 through theuse of tables or formulas. For example, the seller 130 may require salestax to be calculated as a percentage of the sale price of the goods, andthe seller may further define the percentage to be used in thiscalculation in a table that associates a percentage with each possiblestate in which the buyer 110 may live. Similarly, the seller 130 maydefine a table of shipping charges that vary depending on the weight ofthe item, the size of the item, and the address of the buyer 110.Alternatively, the seller 130 may manually enter the additional chargesfor a particular transaction after agreeing to sell goods to the buyer110 for a specified price.

In order to limit the danger of fraud and chargebacks, the paymentenabler 240 may require the seller 130 to undergo an underwriting orapproval process before receiving a personal merchant account. Thisapproval process may be similar to the approval process a retailbusiness must undergo to become a merchant and may vary depending on theparticular instrument type(s) that the seller wants to accept throughthe online cash register.

Typically, the payment enabler 240 retrieves information on which theapproval decision is based through a graphical user interface providedto the seller 130 for creation of the online cash register. Furthermore,the payment enabler 240 may query additional sources based upon theinformation received from the seller 130 in order to obtain additionalinformation that the payment enabler considers in the approval process.In determining whether or not to approve the seller 130 for the personalmerchant account or for accepting payments through a particular paymentinstrument type, the payment enabler 240 may require the seller 130 toprovide such information as the seller's name, address, social securitynumber, e-mail address, estimated total sales for the products to besold, type of products to be sold, how long the seller has beenassociated with the transaction facilitator 230, feedback received bythe transaction facilitator 230 from customers of the seller, and thecredit history of the seller. The payment enabler 240 may submit theinformation received from the seller 130 to a remote computer node (notshown) for performing the underwriting process.

The payment enabler 240 may make an automated decision whether or not toapprove the seller 130 for the personal merchant account or foraccepting a payment instrument type through an online cash register. Thepayment enabler 240 may base this automated decision upon informationprovided by the seller 130 to the payment enabler and furtherinformation about the seller that the payment enabler obtains from othersources.

Alternatively, the payment enabler 240 may determine that the seller 130does not meet the criteria for either automated approval or automatedrejection. In that case, the payment enabler 240 may refer theunderwriting process to a human credit manager for further review. Inthis further review, the human credit manager may request additionalinformation from the seller 130 or request additional information fromother sources. After final decision, the human credit manager informsthe payment enabler 240 whether or not to approve the seller 130 for thepersonal merchant account or for the payment instrument type underreview.

When performing the underwriting assessment of the seller 130, thepayment enabler 240 may rate the seller using tiered risk assessmentcriteria. For example, the payment enabler 240 may process theinformation provided by the seller 130 to determine if the seller ishigh risk, medium risk, or low risk for fraud and chargebacks. Thepayment enabler 240 may inform potential buyers of the tier into whichthe payment enabler has placed the seller 130, thereby helping a buyer110 to determine whether or not to do business with the seller.Similarly, the tier into which the payment enabler 240 places the seller130 for a particular payment instrument type may determine the maximumamount the seller 130 can receive through that payment instrument forany single transaction. Also, the tier into which the payment enabler240 places the seller 130 may determine whether or not the paymentenabler refers the underwriting process to a human credit manager.

After the seller 130 creates an online cash register, the seller 130 maythen provide the online cash register to buyers in order to receivepayment for the sale of goods. Also, the seller 130 may use the backroomcapabilities of the personal merchant account to view transactionscompleted through the online cash register.

Handling of the payment process through the online cash register occursin a manner analogous to that for the consumer-to-consumer paymentprocess 300. The transaction facilitator 230 provides the paymentenabler 240 with the details of a transaction between the buyer 110 andthe seller 130. The payment enabler 240 then provides the online cashregister for the seller 130 to the buyer 110. The online cash registerdisplays the sale price of the goods the buyer 110 is buying from theseller 130. The online cash register also displays any additionalcharges the seller 130 wishes to charge the buyer 110. Further, theonline cash register includes a form allowing the buyer 110 to pay thetotal price using any of the payment instrument types for which theseller 130 has sought and received approval.

In response to viewing the online cash register, the buyer 110 entersregistration information for a payment instrument of one of the paymentinstrument types available through the online cash register. Thisregistration process for the buyer 110 may be similar to theregistration process shown in any of FIGS. 4A–4E, which are used in theconsumer-to-consumer payment process 300. As with theconsumer-to-consumer payment process 300, the payment enabler 240 maystore the registration information for the payment instrument. In thatway, the payment enabler 240 may process requests from the buyer 110 topay the seller 130 without ever providing the registration informationfor the payment instrument to the seller. This eliminates any necessityfor providing the seller 130 with a general authorization to chargepayment instruments such as credit cards, thereby reducing the danger offraud.

After registration of a payment instrument, the buyer 110 can theninstruct the online cash register provided by the payment enabler 240 topay the seller 130. The payment enabler 240 then obtains anauthorization for a transfer of the total price indicated by the onlinecash register from the buyer 110 through the payment instrument to afirst intermediary bank account of the intermediary 120. Next, thepayment enabler 240 orders a transfer of the total price from a secondintermediary bank account through a pre-registered disbursementinstrument to the seller 130. The first intermediary bank account andthe second intermediary bank account may be identical, or they may beowned by the same entity.

When the online cash register receives instructions from the buyer 110to pay the seller 130 a total price indicated by the online cashregister, the payment enabler 240 assigns the transaction a uniquereference number. Through the backroom capabilities of the personalmerchant account, the seller 130 can view pending and past transactionsand their associated reference numbers. The seller 130 can also use thisreference number to refer to the specific transaction when contactingthe intermediary 120 to discuss a transaction, such as during fraudinvestigations and chargebacks.

Before, during, and after the online cash register's payment process,the payment enabler 240 may perform fraud detection analyses fordetecting fraud by the buyer 110 or the seller 130. Such fraud detectionmethods are known to those skilled in the art. Preventing fraud mayfurther include authenticating the buyer 110 and the seller 130 beforeprocessing a transaction.

FIG. 12 is a logical flow diagram of an exemplary online cash registercreation process 1200. The process 1200 begins with step 1210, in whichthe seller 130 provides the payment enabler 240 with identificationinformation about the seller and requests a personal merchant account.In step 1220, the payment enabler 240 creates the personal merchantaccount. The seller 130 can then access this account at any time througha link from the transaction facilitator 230.

In step 1230, the seller 130 registers a disbursement instrument withthe payment enabler 240. The payment enabler 240 can use thisdisbursement instrument for transferring payment to the seller 130 afterreceipt of the payment through the online cash register.

In step 1240, the seller 130 selects the payment instrument types theseller wishes to offer through the online cash register. In step 1250,the payment enabler 240 requests and receives underwriting assessmentinformation for each payment instrument type selected by the seller instep 1240.

In step 1260, the payment enabler performs an underwriting assessmentfor each payment instrument type to determine whether to let the seller130 offer that payment instrument type in the seller's online cashregister. This underwriting assessment is based upon the underwritingassessment information received in step 1250.

In step 1270, the payment enabler 240 determines if the seller 130 hasbeen approved for at least one payment instrument type. If the seller130 has not been approved for at least one payment instrument type, thenthe “NO” branch is followed to step 1290, and the seller is denied anonline cash register. The process 1200 then ends in step 1295.

Referring again to step 1270, if payment enabler 240 determines that theseller 130 has been approved for at least one payment instrument type,then the “YES” branch is followed to step 1280. In step 1280, thepayment enabler 240 permits the seller 130 to define additional chargesto be added automatically by the online cash register to the sale priceof any goods. Such additional charges may include sales tax, shippingcharges, and handling charges.

As shown in step 1285, the creation of the online cash register iscomplete. The payment enabler 240 will provide the online cash registerto each buyer 110 who agrees to buy goods from the seller 130. Throughthe online cash register, the buyer 110 can then pay the seller 130through any payment method for which the seller 130 has been approvedthrough the underwriting process. The process 1200 then ends in step1295.

The logical flow diagram shown in FIG. 12 illustrates one embodiment inwhich the payment enabler 240 performs an underwriting assessment foreach payment instrument type. Alternatively, the payment enabler 240 mayperform a single underwriting assessment prior to approving the seller130 for a personal merchant account. In this alternative embodiment, thepersonal merchant account is not created until the seller 130 isapproved by the payment enabler 240.

FIG. 13 is a logical flow diagram of an exemplary online cash registerpayment process 1300. The process 1300 begins with step 1310, in whichthe seller 130 agrees to sell goods to the buyer 110 for a specifiedprice. This agreement is arrived at through the transaction facilitator230.

In step 1320, the payment enabler 240 assigns a unique reference numberto the transaction. This reference number enables the seller 130 tomonitor the transaction using the backroom capabilities of the personalmerchant account. The seller 130 can also use this reference number torefer to the transaction when contacting the intermediary 120 to discussthe transaction, such as during fraud investigations and chargebacks.

In step 1330, the payment enabler 240 determines additional charges forthe transaction. For example, the payment enabler 240 may calculatesales tax, shipping charges, and handling charges. In step 1340, thepayment enabler 240 displays the online cash register to the buyer 110.The online cash register shows the price of the goods, the additionalcharges, and the total price. The online cash register also offers thebuyer 110 a choice of payment instrument types to use for paying thetotal price.

In step 1350, the buyer 110 selects one of the payment instrument typesoffered by the online cash register. The buyer 110 then provides theonline cash register with registration information for registering apayment instrument corresponding to the payment instrument typeselected. In step 1355, the buyer 110 sends the online cash register acommand to pay the seller 130.

In response to the command of the buyer 110, in step 1360, the paymentenabler 240 obtains an authorization for a transfer of money from thebuyer through the payment instrument to a first intermediary bankaccount. The amount of money authorized covers the total price shown bythe online cash register. In step 1370, the payment enabler 240 ordersthe transfer of money from a second intermediary bank account throughthe disbursement instrument to the seller 130. The amount of thistransfer covers the amount due to the seller 130. The process 1300 thenends in step 1380.

The invention claimed is:
 1. In an online commerce system including abuyer computer operated by a buyer, a seller computer operated by aseller, and a transaction facilitator comprising a network-accessibletransaction computer that facilitates commercial transactions betweenbuyers and sellers, a method for effecting a cash payment from the buyerto the seller in connection with an online transaction utilizing apayment enabling system operated by a payment enabler, comprising thecomputer-implemented steps of: receiving transaction information fromthe transaction computer in response to a proposed transaction betweenthe buyer and the seller facilitated by the transaction facilitator, thetransaction information including a transaction amount; communicatinginformation to the buyer computer system for displaying the transactioninformation and enabling the selection by the buyer of a prearrangedcash deposit payment instrument for use in effecting payment inconnection with the transaction, the prearranged cash deposit paymentinstrument issued by a cash deposit payment instrument processor;receiving cash deposit payment instrument information input by the buyervia the buyer computer, the cash deposit payment instrument informationincluding buyer information; determining a required deposit amountincluding at least the transaction amount and corresponding to theamount of cash that the buyer must deposit with the cash deposit paymentinstrument processor to find the prearranged cash deposit paymentinstrument; storing a cash deposit payment instrument registrationrecord in a memory associated with the payment enabling system, theregistration record storing the buyer information, the required depositamount, and a data field indicating whether the required cash deposithas been received by the cash deposit payment instrument processor;communicating information to the cash deposit payment instrumentprocessor comprising the required deposit amount and buyer information;in response to receipt of information from the cash deposit paymentinstrument processor that the required deposit amount has been receivedat a deposit location registered with the cash deposit paymentinstrument processor, updating the data field in the registration recordindicating that the required deposit amount has been received by thecash deposit payment instrument processor; and in response to updatingof the data field in the registration record indicating that therequired deposit amount has been received by the cash deposit paymentinstrument processor, effecting completion of the transaction by makingpayment to the seller.
 2. The method of claim 1, further comprising thesteps of: communicating information to the buyer computer system fordisplaying payment instrument information and enabling the registrationby the buyer of the cash deposit payment instrument for use in effectingpayment in connection with the transaction; and receiving paymentinstrument registration information input by the buyer via the buyercomputer, the payment instrument registration information includinginformation indicating selection of the prearranged cash deposit paymentinstrument chosen by the buyer.
 3. The method of claim 2, wherein theprearranged cash deposit payment instrument is one of a plurality ofselectable payment instruments that the buyer may select for effectingpayments and wherein the information communicated to the buyer computersystem for displaying payment instrument information and enabling theregistration of a payment instrument comprises information relating tothe plurality of selectable payment instruments.
 4. The method of claim2, wherein the payment instrument registration information includes abuyer-entered deposit amount.
 5. The method of claim 4, wherein thebuyer-entered deposit amount is at least the required deposit amount. 6.The method of claim 2, wherein the step of receiving payment instrumentregistration information input by the buyer via the buyer computercomprises receiving information corresponding to multiple paymentinstruments.
 7. The method of claim 2, wherein the steps ofcommunicating information for displaying payment instrument informationand receiving payment instrument registration information occur prior tothe transaction between the buyer and the seller in a staticregistration process.
 8. The method of claim 2, wherein the steps ofcommunicating information for displaying payment instrument informationand receiving payment instrument registration information occur after tothe transaction between the buyer and the seller in a dynamicregistration process.
 9. The method of 1, wherein the required depositamount is at least the transaction amount.
 10. The method of claim 1,wherein the buyer information includes buyer identification information,and wherein the buyer identification information is communicated to thecash deposit instrument payment processor.
 11. The method of claim 1,further comprising the step of electronically requesting authorizationfor payment in an amount of at least the transaction amount for theprearranged cash deposit payment instrument from the cash depositpayment instrument processor.
 12. The method of claim 11, wherein theamount requested for authorization in the requesting authorization stepcomprises the required deposit amount.
 13. The method of claim 11,wherein receipt of information from the cash deposit payment instrumentprocessor that the required cash deposit has been made at the depositlocation results from the requesting authorization step.
 14. The methodof claim 11, wherein the amount for which authorization is sought in therequesting authorization step includes any additional charges associatedwith the transaction.
 15. The method of claim 1, further comprising thestep of determining if goods of the transaction have been acceptablydelivered prior to making payment to the seller.
 16. The method of claim1, further comprising step of, in response to information from the cashdeposit payment instrument processor that the required deposit amounthas been received from the buyer at the deposit location, transferringfunds received from the buyer to a bank account of an intermediary,prior to making payment to the seller.
 17. The method of claim 16,wherein the transfer of funds from the cash deposit payment instrumentprocessor to the bank account of the intermediary is by direct deposit.18. The method of claim 1, further comprising the steps of:communicating information to the seller computer system for displayingdisbursement instrument information and enabling the registration by theseller of a disbursement instrument for use in receiving payment inconnection with the transaction; and wherein the step of effectingcompletion of the transaction by making payment to the seller comprisesutilizing the registered disbursement instrument for making the payment.19. A system for effecting payment for goods purchased by a buyer usinga buyer computer system from a seller using a seller computer system inan online transaction facilitated by a transaction facilitator, apayment to the seller conditioned on receipt of a cash deposit by thebuyer at a deposit location registered to a cash deposit paymentinstrument processor, the transaction facilitator operating anetwork-accessible transaction computer that facilitates commercialtransactions between buyers and sellers, comprising: a payment enablingsystem; an interface for data communications with the buyer computer; aninterface for data communications with the seller computer; an interfacefor data communications with the transaction computer; an interface fordata communications with at least one cash deposit payment instrumentprocessor that issues cash deposit payment instruments; the paymentenabling system receiving transaction information from the transactioncomputer in response to a proposed transaction between the buyer and theseller facilitated by the transaction facilitator, the transactioninformation including a transaction amount; the payment enabling systemcommunicating information to the buyer computer system for displayingthe transaction information and enabling the selection by the buyer of aprearranged cash deposit payment instrument for use in effecting paymentin connection with the transaction; the payment enabling system furtherdetermining a required deposit amount including at least the transactionamount and corresponding to the amount of cash that the buyer mustdeposit with the cash deposit payment instrument processor to fund theprearranged cash deposit payment instrument; the payment enabling systemfurther storing a cash deposit payment instrument registration record ina memory, the registration record storing the buyer information, therequired deposit amount, and a data field indicating whether therequired cash deposit has been received by the cash deposit paymentinstrument processor; the payment enabling system further communicatinginformation to the cash deposit payment instrument processor comprisingthe required deposit amount and buyer information; the payment enablingsystem further, in response to receipt of information from the cashdeposit payment instrument processor that the required deposit amounthas been received at a deposit location registered with the cash depositpayment instrument processor, updating the data field in theregistration record indicating that the required deposit amount has beenreceived by the cash deposit payment instrument processor; and thepayment enabling system further, in response to updating of the datafield in the registration record indicating that the required depositamount has been received by the cash deposit payment instrumentprocessor, effecting completion of the transaction by making payment tothe seller.
 20. The system of claim 19, wherein the payment enablingsystem communicates information to the buyer computer system fordisplaying payment instrument information and enabling the registrationby the buyer of at least one payment instrument for use in effectingpayment in connection with the transaction; and wherein the paymentenabling system receives payment instrument registration informationinput by the buyer via the buyer computer, the payment instrumentregistration information including the buyer information and informationindicating selection of the prearranged cash deposit payment instrumentfor effecting payment to the seller in connection with the transaction.21. The system of claim 20, wherein the prearranged cash deposit paymentinstrument is one of a plurality of selectable payment instruments thatthe buyer may select for effecting payment, and wherein the informationcommunicated to the buyer computer system for displaying paymentinstrument information and enabling the registration of a paymentinstrument comprises information relating to the plurality of selectablepayment instruments.
 22. The system of claim 20, wherein the operationof the payment enabling system of receiving payment instrumentregistration information input by the buyer via the buyer computercomprises receiving information corresponding to multiple paymentinstruments.
 23. The system of claim 20, wherein the operations ofcommunicating information for displaying payment instrument informationand receiving payment instrument registration information occur prior tothe transaction between the buyer and the seller in a staticregistration process.
 24. The system of claim 20, wherein the operationsof communicating information for displaying payment instrumentinformation and receiving payment instrument registration informationoccur after to the transaction between the buyer and the seller in adynamic registration process.
 25. The system of claim 20, wherein thepayment instrument registration information includes a buyer-entereddeposit amount.
 26. The system of claim 25, wherein the buyer-entereddeposit amount is at least the required deposit amount.
 27. The systemof claim 19, wherein the buyer information includes buyer identificationinformation, and wherein the buyer identification information iscommunicated to the cash deposit instrument payment processor.
 28. Thesystem of claim 19, wherein the payment enabling system electronicallyrequests authorization for payment in an amount of at least thetransaction amount for the prearranged cash deposit payment instrumentfrom the cash deposit payment instrument processor.
 29. The system ofclaim 28, wherein the amount requested for authorization in therequesting authorization operation comprises the required depositamount.
 30. The system of claim 28, wherein receipt of information fromthe cash deposit payment instrument processor that the required cashdeposit has been made at the deposit location results from therequesting authorization operation.
 31. The system of claim 28, whereinthe amount for which authorization is sought in the requestingauthorization operation includes any additional charges associated withthe transaction.
 32. The system of 19, wherein the required depositamount is at least the transaction amount.
 33. The system of claim 19,wherein the payment enabling system determines if goods of thetransaction have been acceptably delivered prior to making payment tothe seller.
 34. The system of claim 19, wherein the payment enablingsystem, in response to information from the cash deposit paymentinstrument processor that the required deposit amount has been receivedfrom the buyer at the deposit location, transfers funds received fromthe buyer to a bank account of an intermediary, prior to making paymentto the seller.
 35. The system of claim 34, wherein the transfer of fundsfrom the cash deposit payment instrument processor to the bank accountof the intermediary is by direct deposit.
 36. The system of claim 19,wherein the payment enabling system: communicates information to theseller computer system for displaying disbursement instrumentinformation and enabling the registration by the seller of adisbursement instrument for use in receiving payment in connection withthe transaction; and wherein the operation of effecting completion ofthe transaction by making payment to the seller comprises utilizing theregistered disbursement instrument for making the payment.
 37. In anonline commerce system including a buyer computer system operated by abuyer, a seller computer system operated by a seller, and a transactionfacilitator comprising a network-accessible transaction computer thatfacilitates commercial transactions between buyers and sellers, a methodfor effecting a cash payment from the buyer to the seller in connectionwith an online transaction utilizing a payment enabling system operatedby a payment enabler, comprising the computer-implemented steps of:receiving transaction information from the transaction computer inresponse to a proposed transaction between the buyer and the sellerfacilitated by the transaction facilitator, the transaction informationincluding a transaction amount; communicating information to the buyercomputer system for displaying payment instrument information andenabling the registration by the buyer of a payment instrument for usein effecting payment in connection with the transaction, the paymentinstrument comprising a prearranged cash deposit payment instrumentissued by a cash deposit payment instrument processor; receiving paymentinstrument registration information input by the buyer via the buyercomputer, the payment instrument registration information includingbuyer information and indicating selection of the prearranged cashdeposit payment instrument chosen by the buyer for effecting payment tothe seller in connection with the transaction; determining a requireddeposit amount including at least the traction amount and correspondingto the amount of cash that the buyer must deposit with the cash depositpayment instrument processor to fund the prearranged cash depositpayment instrument; storing a cash deposit payment instrumentregistration record in a memory associated with the payment enablingsystem the registration record storing the buyer information, therequired deposit amount, and a data field indicating whether therequired cash deposit has been received by the cash deposit paymentinstrument processor; communicating information to the cash depositpayment instrument processor comprising the required deposit amount andbuyer information; in response to receipt of information from the cashdeposit payment instrument processor that the required deposit amounthas been received at a deposit location registered with the cash depositpayment instrument processor, updating the data field in theregistration record indicating that the required deposit amount has beenreceived by the cash deposit payment instrument processor; and inresponse to updating of the data field in the registration recordindicating that the required deposit amount has been received by thecash deposit payment instrument processor, effecting completion of thetransaction by making payment to the seller.
 38. The method of claim 37,wherein the prearranged cash deposit payment instrument is one of aplurality of selectable payment instruments that the buyer may selectfor effecting payment, and wherein the information communicated to thebuyer computer system for displaying payment instrument information andenabling the registration of a payment instrument comprises informationrelating to the plurality of selectable payment instruments.
 39. Themethod of claim 37, wherein the buyer information includes buyeridentification information, and wherein the buyer identificationinformation is communicated to the cash deposit instrument paymentprocessor.
 40. The method of claim 37, further comprising the step ofelectronically requesting authorization for payment in an amount of atleast the transaction amount for the prearranged cash deposit paymentinstrument from the cash deposit payment instrument processor.
 41. Themethod of claim 40, wherein the amount requested for authorization inthe requesting authorization step comprises the required deposit amount.42. The method of claim 40, wherein receipt of information from the cashdeposit payment instrument processor that the required cash deposit hasbeen made at the deposit location results from the requestingauthorization step.
 43. The method of claim 40, wherein the amount forwhich authorization is sought in the requesting authorization stepincludes any additional charges associated with the transaction.
 44. Themethod of claim 37, wherein the payment instrument registrationinformation includes a buyer-entered deposit amount.
 45. The method ofclaim 44, wherein the buyer-entered deposit amount is at least therequired deposit amount.
 46. The method of 37, wherein the requireddeposit amount is at least the transaction amount.
 47. The method ofclaim 37, further comprising the step of determining if goods of thetransaction have been acceptably delivered prior to making payment tothe seller.
 48. The method of claim 37, further comprising step of, inresponse to information from the cash deposit payment instrumentprocessor that the required deposit amount has been received from thebuyer at the deposit location, transferring funds received from thebuyer to a bank account of an intermediary, prior to making payment tothe seller.
 49. The method of claim 48, wherein the transfer of fundsfrom the cash deposit payment instrument processor to the bank accountof the intermediary is by direct deposit.
 50. The method of claim 37,wherein the step of receiving payment instrument registrationinformation input by the buyer via the buyer computer comprisesreceiving information corresponding to multiple payment instruments. 51.The method of claim 37, further comprising the steps of: communicatinginformation to the seller computer system for displaying disbursementinstrument registration information and enabling the registration by theseller of a disbursement instrument for use in receiving payment inconnection with the transaction; and wherein the step of effectingcompletion of the transaction by making payment to the seller comprisesutilizing the registered disbursement instrument for making the payment.52. The method of claim 37, wherein the steps of communicatinginformation for displaying payment instrument information and receivingpayment instrument registration information occur prior to thetransaction between the buyer and the seller in a static registrationprocess.
 53. The method of claim 37, wherein the steps of communicatinginformation for displaying payment instrument information and receivingpayment instrument registration information occur after to thetransaction between the buyer and the seller in a dynamic registrationprocess.
 54. A system for effecting payment for goods purchased by abuyer using a buyer computer system from a seller using a sellercomputer system in an online transaction facilitated by a transactionfacilitator, a payment to the seller conditioned on receipt of a cashdeposit by the buyer at a deposit location registered to a cash depositpayment instrument processor, the transaction facilitator operating anetwork-accessible transaction computer that facilitates commercialtransactions between buyers and sellers, comprising: a payment enablingsystem; an interface for data communications with the buyer computer; aninterface for data communications with the seller computer; an interfacefor data communications with the action computer; an interface for datacommunications with at least one payment instrument processor; thepayment enabling system receiving transaction information from thetransaction computer in response to a proposed transaction between thebuyer and the seller facilitated by the transaction facilitator, thetransaction information including a transaction amount; the paymentenabling system communicating information to the buyer computer systemfor displaying payment instrument information and enabling theregistration by the buyer of a payment instrument for use in effectingpayment in connection with the transaction, the payment instrumentcomprising a prearranged cash deposit payment instrument issued by thecash deposit payment instrument processor; the payment enabling systemfurther receiving payment instrument registration information input bythe buyer via the buyer computer, the payment instrument registrationinformation including buyer information and indicating selection of theprearranged cash deposit payment instrument for effecting payment to theseller in connection with the transaction; the payment enabling systemdetermining a required deposit amount including at least the transactionamount and corresponding to the amount of cash that the buyer mustdeposit with the cash deposit payment instrument processor to fund theprearranged cash deposit payment instrument; the payment enabling systemstoring a cash deposit payment instrument registration record in amemory, the registration record storing the buyer information, therequired deposit amount, and a data field indicating whether therequired cash deposit has been received by the cash deposit paymentinstrument processor; the payment enabling system communicatinginformation to the cash deposit payment instrument processor comprisingthe required deposit amount and buyer information; the payment enablingsystem, in response to receipt of information from the cash depositpayment instrument processor that the required deposit amount has beenreceived at a deposit location registered with the cash deposit paymentinstrument processor, updating the data field in the registration recordindicating that the required deposit amount has been received by thecash deposit payment instrument processor; and the payment enablingsystem, in response to updating of the data field in the registrationrecord indicating that the required deposit amount has been received bythe cash deposit payment instrument processor, effecting completion ofthe transaction by making payment to the seller.
 55. The system of claim54, wherein the prearranged cash deposit payment instrument is one of aplurality of selectable payment instruments that the buyer may selectfor effecting payment, and wherein the information communicated to thebuyer computer system for displaying payment instrument information andenabling the registration of a payment instrument comprises informationrelating to the plurality of selectable payment instruments.
 56. Thesystem of claim 54, wherein the buyer information includes buyeridentification information, and wherein the buyer identificationinformation is communicated to the cash deposit instrument paymentprocessor.
 57. The system of claim 54, wherein the payment enablingsystem electronically requests authorization for payment in an amount ofat least the transaction amount for the prearranged cash deposit paymentinstrument from the cash deposit payment instrument processor.
 58. Thesystem of claim 57, wherein the amount requested for authorization inthe requesting authorization operation comprises the required depositamount.
 59. The system of claim 57, wherein receipt of information fromthe cash deposit payment instrument processor that the required cashdeposit has been made at the deposit location results from therequesting authorization operation.
 60. The system of claim 57, whereinthe amount for which authorization is sought in the requestingauthorization operation includes any additional charges associated withthe transaction.
 61. The system of claim 54, wherein the paymentinstrument registration information includes a buyer-entered depositamount.
 62. The system of claim 61, wherein the buyer-entered depositamount is at least the required deposit amount.
 63. The system of 54,wherein the required deposit amount is at least the transaction amount.64. The system of claim 54, wherein the payment enabling systemdetermines if goods of the transaction have been acceptably deliveredprior to making payment to the seller.
 65. The system of claim 54,wherein the payment enabling system, in response to information from thecash deposit payment instrument processor that the required depositamount has been received from the buyer at the deposit location,transfers funds received from the buyer to a bank account of anintermediary, prior to making payment to the seller.
 66. The system ofclaim 65, wherein the transfer of funds from the cash deposit paymentinstrument processor to the bank account of the intermediary is bydirect deposit.
 67. The system of claim 54, wherein the operation of thepayment enabling system of receiving payment instrument registrationinformation input by the buyer via the buyer computer comprisesreceiving information corresponding to multiple payment instruments. 68.The system of claim 54, wherein the payment enabling system:communicates information to the seller computer system for displayingdisbursement instrument information and enabling the registration by theseller of a disbursement instrument for use in receiving payment inconnection with the transaction; and wherein the operation of effectingcompletion of the transaction by making payment to the seller comprisesutilizing the registered disbursement instrument for making the payment.69. The system of claim 54, wherein operations of communicatinginformation for displaying payment instrument information and receivingpayment instrument registration information occur prior to thetransaction between the buyer and the seller in a static registrationprocess.
 70. The system of claim 54, wherein operations of communicatinginformation for displaying payment instrument information and receivingpayment instrument registration information occur after to thetransaction between the buyer and the seller in a dynamic registrationprocess.
 71. In an online commerce system including a buyer computeroperated by a buyer, a seller computer operated by a seller, atransaction facilitator comprising a network-accessible transactioncomputer that facilitates commercial transactions between buyers andsellers, a payment enabling system, and one or more payment instrumentprocessors, a method for effecting a cash payment from said buyer tosaid seller in connection with an online transaction, comprising thecomputer-implemented steps of: at the transaction computer, generatingtransaction information corresponding to a transaction between saidbuyer and said seller, the transaction information including at least atransaction amount, and communicating the transaction information to thepayment enabling system; at the payment enabling system, receiving thetransaction information from the transaction computer; communicatinginformation from the payment enabling system to the buyer computersystem for displaying payment instrument information and enabling theregistration by the buyer of one of a plurality of payment instrumentsfor use in effecting payment in connection with the transaction, theplurality of payment instruments including a prearranged cash depositpayment instrument issued by a cash deposit payment instrumentprocessor; receiving at the payment enabling system payment instrumentregistration information input by the buyer via the buyer computer, thepayment instrument registration information including buyer informationand indicating selection of the prearranged cash deposit paymentinstrument for effecting payment to the seller in connection with thetransaction; determining at the payment enabling system a requireddeposit amount, including at least the transaction amount, correspondingto the amount of cash that the buyer must deposit with the cash depositpayment instrument processor to fund the prearranged cash depositpayment instrument; storing a cash deposit payment instrumentregistration record in a memory associated with the payment enablingsystem, the registration record storing the buyer information, therequired deposit amount, and a data field indicating whether therequired cash deposit has been received by the cash deposit paymentinstrument processor; communicating the buyer information and therequired deposit amount from the payment enabling system to the cashdeposit payment instrument processor; upon receipt of finds of at leastthe required deposit amount at a deposit location associated with thecash deposit instrument payment processor, communicating information tothe payment enabling system that the required deposit amount has beenreceived; in response to receipt of information at the payment enablingsystem from the cash deposit payment instrument processor that therequired deposit amount has been received, updating the data field inthe registration record indicating that the required deposit amount hasbeen received by the cash deposit payment instrument processor; inresponse to receipt of information at the payment enabling systemindicating that the required deposit amount has been received by thecash deposit payment instrument processor, communicating information tothe seller computer for notifying the seller that payment in connectionwith the transaction has been arranged and providing instructions to theseller to ship the goods; and in further response to receipt ofinformation at the payment enabling system indicating that the requireddeposit amount has been received by the cash deposit payment instrumentprocessor, effecting completion of the transaction by making payment tothe seller.
 72. The method of claim 71, wherein the step of effectingcompletion of the transaction by making payment to the seller isconditioned upon the prior receipt of information indicating that thegoods have been acceptably delivered to the buyer.
 73. The method ofclaim 71, wherein the prearranged cash deposit payment instrument is oneof a plurality of selectable payment instruments that the buyer mayselect for effecting payment, and wherein the information communicatedto the buyer computer system for displaying payment instrumentinformation and enabling the registration of a payment instrumentcomprises information relating to the plurality of selectable paymentinstruments.
 74. The method of claim 71, wherein the buyer informationincludes buyer identification information, and wherein the buyeridentification information is communicated to the cash depositinstrument payment processor.
 75. The method of claim 71, furthercomprising the step of the payment enabling system electronicallyrequesting authorization for payment in an amount of at least thetransaction amount for the prearranged cash deposit payment instrumentfrom the cash deposit payment instrument processor.
 76. The method ofclaim 75, wherein the amount requested for authorization in therequesting authorization step comprises the required deposit amount. 77.The method of claim 75, wherein receipt of information from the cashdeposit payment instrument processor that the required cash deposit hasbeen made at the deposit location results from the requestingauthorization step.
 78. The method of claim 75, wherein the amount forwhich authorization is sought in the requesting authorization stepincludes any additional charges associated with the transaction.
 79. Themethod of claim 71, wherein the payment instrument registrationinformation includes a buyer-entered deposit amount.
 80. The method ofclaim 79, wherein the buyer-entered deposit amount is at least therequired deposit amount.
 81. The method of 71, wherein the requireddeposit amount is at least the transaction amount.
 82. The method ofclaim 71, further comprising the step of determining if goods of thetransaction have been acceptably delivered prior to making payment tothe seller.
 83. The method of claim 71, further comprising step of, inresponse to information from the cash deposit payment instrumentprocessor that the required deposit amount has been received from thebuyer at the deposit location, transferring funds received from thebuyer to a bank account of an intermediary, prior to making payment tothe seller.
 84. The method of claim 83, wherein the transfer of fundsfrom the cash deposit payment instrument processor to the bank accountof the intermediary is by direct deposit.
 85. The method of claim 71,wherein the step of receiving payment instrument registrationinformation input by the buyer via the buyer computer comprisesreceiving information corresponding to multiple payment instruments. 86.The method of claim 71, further comprising the steps of: communicatinginformation to the seller computer system for displaying disbursementinstrument information and enabling the registration by the seller of adisbursement instrument for use in receiving payment in connection withthe transaction; and wherein the step of effecting completion of thetransaction by making payment to the seller comprises utilizing theregistered disbursement instrument for making the payment.
 87. Themethod of claim 71, wherein the steps of communicating information fordisplaying payment instrument information and receiving paymentinstrument registration information occur prior to the transactionbetween the buyer and the seller in a static registration process. 88.The method of claim 71, wherein the steps of communicating informationfor displaying payment instrument information and receiving paymentinstrument registration information occur after to the transactionbetween the buyer and the seller in a dynamic registration process. 89.A system for effecting a cash payment from a buyer to a seller inconnection with an online transaction, the buyer utilizing a buyercomputer system and the seller utilizing a seller computer system tocommunicate via a computer network with a transaction facilitator thatfacilitates commercial transactions between buyers and sellers,comprising a network-accessible transaction computer operated by thetransaction facilitator generating transaction information correspondingto a transaction between a buyer and a seller and communicating thetransaction information to a payment enabling system, the transactioninformation including at least a transaction amount; one or more paymentinstrument processors that effect payments based on a paymentinstrument, each payment instrument processor, in response to a requestfor a payment authorization in a requested amount from a paymentenabling system, determining whether to authorize the payment in therequested amount, and communicating information indicating authorizationof the payment in the requested amount to the payment enabling system,at least one of the payment instrument processors comprising a cashdeposit payment instrument processor that issues prearranged cashdeposit payment instruments; a payment enabling system effectingpayments utilizing payment instruments issued by the payment instrumentprocessors, the payment enabling system communicating information to thebuyer computer system for displaying payment instrument information andenabling the registration by the buyer of one or more paymentinstruments for use in effecting payment in connection with thetransaction, the one or more payment instruments including at least theprearranged cash deposit payment instrument issued by the cash depositpayment instrument processor; the payment enabling system receivingpayment instrument registration information input by the buyer via thebuyer computer, the payment instrument registration informationincluding buyer information and indicating selection of the prearrangedcash deposit payment instrument for effecting payment to the seller inconnection with the transaction; the payment enabling system determininga required deposit amount, including at least the transaction amount,corresponding to the amount of cash that the buyer must deposit with thecash deposit payment instrument processor to fund the prearranged cashdeposit payment instrument; the payment enabling system storing a cashdeposit payment instrument registration record in a memory, theregistration record storing the buyer information, the required depositamount, and a data field indicating whether the required cash deposithas been received by the cash deposit payment instrument processor; thepayment enabling system communicating the buyer information and therequired deposit amount to the cash deposit payment instrumentprocessor; the cash deposit payment instrument processor, in response toreceipt of the buyer information and the required deposit amount andupon receipt of funds of at least the required deposit amount at adeposit location associated with the cash deposit instrument paymentprocessor, communicating information to the payment enabling system thatthe required deposit amount has been received; the payment enablingsystem, in response to receipt of information from the cash depositpayment instrument processor that the required deposit amount has beenreceived, updating the data field in the registration record indicatingthat the required deposit amount has been received by the cash depositpayment instrument processor; the payment enabling system, in responseto receipt of information indicating that the required deposit amounthas been received by the cash deposit payment instrument processor,communicating information to the seller computer for notifying theseller that payment in connection with the transaction has been arrangedand providing instructions to the seller to ship the goods; and thepayment enabling system, in further response to receipt of informationindicating that the required deposit amount has been received by thecash deposit payment instrument processor, effecting completion of thetransaction by making payment to the seller.
 90. The system of claim 89,wherein the operation of effecting completion of the transaction bymaking payment to the seller is conditioned upon the prior receipt bythe payment enabling system of information indicating that the goodshave been acceptably delivered to the buyer.
 91. The system of claim 89,wherein the prearranged cash deposit payment instrument is one of aplurality of selectable payment instruments that the buyer may selectfor effecting payment, and wherein the information communicated to thebuyer computer system for displaying payment instrument information andenabling the registration of a payment instrument comprises informationrelating to the plurality of selectable payment instruments in additionto the cash deposit payment instrument.
 92. The system of claim 89,wherein the buyer information includes buyer identification information,and wherein the payment enabling system communicates the buyeridentification information to the cash deposit instrument paymentprocessor.
 93. The system of claim 89, wherein the payment enablingsystem electronically requests authorization for payment in an amount ofat least the transaction amount for the prearranged cash deposit paymentinstrument from the cash deposit payment instrument processor.
 94. Thesystem of claim 93, wherein the amount requested for authorization inthe requesting authorization step comprises the required deposit amount.95. The system of claim 93, wherein receipt of information by thepayment enabling system from the cash deposit payment instrumentprocessor that the required cash deposit has been made at the depositlocation results from the requesting authorization operation.
 96. Thesystem of claim 93, wherein the amount for which authorization is soughtin the requesting authorization operation includes any additionalcharges associated with the transaction.
 97. The system of claim 89,wherein the payment instrument registration information includes abuyer-entered deposit amount.
 98. The system of claim 97, wherein thebuyer-entered deposit amount is at least the required deposit amount.99. The system of 89, wherein the required deposit amount is at leastthe transaction amount.
 100. The system of claim 89, wherein the paymentenabling system determines if goods of the transaction have beenacceptably delivered prior to making payment to the seller.
 101. Thesystem of claim 89, wherein the payment enabling system, in response toinformation from the cash deposit payment instrument processor that therequired deposit amount has been received from the buyer at the depositlocation, transfers funds received from the buyer to a bank account ofan intermediary, prior to making payment to the seller.
 102. The systemof claim 101, wherein the transfer of funds from the cash depositpayment instrument processor to the bank account of the intermediary isby direct deposit.
 103. The system of claim 89, wherein the operation ofreceiving payment instrument registration information input by the buyervia the buyer computer comprises receiving information corresponding tomultiple payment instruments.
 104. The system of claim 89, wherein thepayment enabling system: communicates information to the seller computersystem for displaying disbursement instrument information and enablingthe registration by the seller of a disbursement instrument for use inreceiving payment in connection with the transaction; and wherein thestep of effecting completion of the transaction by making payment to theseller comprises utilizing the registered disbursement instrument formaking the payment.
 105. The system of claim 89, wherein operations ofcommunicating information for displaying payment instrument informationand receiving payment instrument registration information occur prior tothe transaction between the buyer and the seller in a staticregistration process.
 106. The system of claim 89, wherein operations ofcommunicating information for displaying payment instrument informationand receiving payment instrument registration information occur after tothe transaction between the buyer and the seller in a dynamicregistration process.